Embedded Systems Learning Academy - User contributions [en]

S19: Tech Savy

2020-07-10T21:05:48Z

Proj user22: /* Project Source Code */

[[File:TechSavy_logo.jpeg| 300px |LOGO|bottom|right]]

== '''Tech Savy RC Car''' ==

{|
|
|
|[[File:CMPE243_Tech_Savy_Car_Side.jpg|300px|thumb|left|Tech_Savy Side Open view]]
|
|
|
|
|[[File:CMPE243_Tech_Savy_Car_RearView.jpg|500px|thumb|center|Tech_Savy View]]
|
|
|
|
|[[File:CMPE243_Tech_Savy_Car_Top_View.jpeg|300px|thumb|right|Tech_Savy Top Open view]]
|
|
|}

== '''Abstract''' ==

In this project our main aim to build a Self-Navigating Car named Tech Savy, that navigates from a source location to a selected destination by avoiding obstacles in its path using sensors and motors.

[[File:Car_Working.png|800px|thumb|center|Main Building Blocks of Tech Savy]]

== '''Introduction & Objectives''' ==

The key features support by the system are

1. A Google-map based Android application is developed which will update the live location of RC car given by GPS to Bridge over Bluetooth.Android app is used to get information from all the Modules and will show live data of MOTOR, SENSORS, GPS and COMPASS and we can set the final destination so that car can drive to the destination.

2. The car will be integrated with the GPS, Compass, Bluetooth, multiple sensors such as Ultrasonic sensors and RPM sensors to fulfill the purpose of navigation, obstacle detection, and avoidance

3. LIDAR and Ultrasonic Sensor is used for obstacle detection and avoidance in all the angles in the view of 360 degrees.

4. Motor drives the car by Route Calculation done on GPS using the shortest distance path algorithm between current location and destination and connects to the self-driving RC car via Bluetooth to send the GPS Coordinates and Maneuvering to the selected destination and Self- Adjusting the speed of the car on Ramp.

5. LEDs and LED Display are used for debugging and to get all relevant information about the status of the car, in real time and LCD Display is used to give more detailed information related to the car.

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

'''CAR Objectives'''
'''1. Master Controller''' - Handles the Route Manuevering,Path Planning and Obstacle Avoidance
'''2. Sensor Controller''' - Detects the surrounding objects
'''3. Geo Controller''' - Provides current location in the form of coordinates and navigate car using CMPS11
'''4. Motor Controller''' - controls the movement of the Car.
'''5. Bridge controller''' - Interfaces the system using Bluetooth to an Android application.

'''Team Objectives'''
'''1.''' Learn each and every module as much as possible, in order to develop an industrial product.
'''2.''' Achieve 100% code coverage, during unit testing.
'''3.''' Document and track all the bugs encountered during development, unit testing, and field testing.

{|
|[[ File: CmpE243_TechSavy_System_Design.png|650px|thumb|left|System Architecture]]

[[ File: App_log.jpeg |300px|thumb|right|Android Application]]
|
|}

== '''Team Members & Technical Responsibilities''' ==
[[File:cmpe243_S19_TechSavy_members.jpeg|thumb|500x500px|TEAM TECH SAVY|right]]

* Git Project Link: [https://gitlab.com/tech-savycmpe243/cmpe243_techsavy_rc_car Tech Savy ]

* Master Controller
**'''''[http://linkedin.com/in/aakash-chitroda-17841740 Aakash Chitroda]'''''

* Motor Controller
**'''''[https://www.linkedin.com/in/jay-parsana-59059a860 Jay Parsana]'''''
**'''''[http://linkedin.com/in/vatsal-makani-540650b2 Vatsal Makani]'''''
**'''''[http://linkedin.com/in/aakash-chitroda-17841740 Aakash Chitroda]'''''

* Geographical Controller
**'''''[https://www.linkedin.com/in/vidushi-jain-048b992a Vidushi Jain]'''''

* Sensor Controller
**'''''[https://www.linkedin.com/in/halak-vyas-4646a4145 Halak Vyas]'''''
**'''''[http://linkedin.com/in/aakash-chitroda-17841740 Aakash Chitroda]'''''

* Communication Bridge Controller
**'''''[https://www.linkedin.com/in/akshata-kulkarni-a9145b62 Akshata Kulkarni]'''''
**'''''[https://www.linkedin.com/in/vidushi-jain-048b992a Vidushi Jain]'''''
**'''''[https://www.linkedin.com/in/saumil-shah-a49849166 Saumil Shah]'''''

* Android Application
**'''''[https://www.linkedin.com/in/saumil-shah-a49849166 Saumil Shah]'''''
**'''''[https://www.linkedin.com/in/akshata-kulkarni-a9145b62 Akshata Kulkarni]'''''

* LCD Interfacing & UI Designing
**'''''[http://linkedin.com/in/aakash-chitroda-17841740 Aakash Chitroda]'''''
**'''''[http://linkedin.com/in/vatsal-makani-540650b2 Vatsal Makani]'''''

* Hardware PCB Integration
**'''''[https://www.linkedin.com/in/prashantgandhi27 Prashant Gandhi]'''''
**'''''[http://linkedin.com/in/vatsal-makani-540650b2 Vatsal Makani]'''''

* Testing
**'''''[http://linkedin.com/in/aakash-chitroda-17841740 Aakash Chitroda]'''''
**'''''[https://www.linkedin.com/in/jay-parsana-59059a860 Jay Parsana]'''''
**'''''[https://www.linkedin.com/in/vidushi-jain-048b992a Vidushi Jain]'''''

 

== '''Administrative Responsibilities''' ==
{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|- style="vertical-align: top;"
! colspan="5" style="background:#7acee2" | Administrative Roles 
|-
! style="text-align: left;" |
* Team Lead 
| Aakash Chitroda 
|-
! style="text-align: left;" |
* Finance Manager
| Halak Vyas
|-
! style="text-align: left;" |
* Git Repository Manager 
| Vatsal Makani
|-
! style="text-align: left;" |
* Wiki Report Manager 
| Vidushi Jain
|-
! style="text-align: left;" |
* Bill of Materials Manager 
| Jay Parsana
|}

== '''Team Deliverables Schedule''' ==

{| class="wikitable"
|-
! scope="col" style="text-align: left;" style="background:#7acee2;" | WEEK
! scope="col" style="text-align: left;" style="background:#7acee2;" | 
START DATE 
! scope="col" style="text-align: left;" style="background:#7acee2;" | 
END DATE 
! scope="col" style="text-align: left;" style="background:#7acee2;" | 
TASK DETAILS 
! scope="col" style="text-align: left;" style="background:#7acee2;" | 
STATUS 
|-
| '''1''' || '''26 Feb 2019''' || '''4 March 2019''' ||
*'''Create and establish GitLab repository'''
*'''Establish slack channel and invite Preet'''
*'''Look through previous years projects and study it'''
*'''Distribute major roles among team members'''
|| Completed Completed Completed Completed 
|-
| '''2''' || '''05 March 2019''' || '''12 March 2019''' ||
*'''Create a Bill of Materials.'''
*'''Select and order an RC car.'''
*'''Make Repo on Gitlab for all modules - Follow Naming Convention.'''
|| Completed Completed Completed
|-
| '''3''' || '''13 March 2019'''|| '''19 March 2019''' ||
*'''Select Part Number for Sensors (Halak, Aakash)'''
*'''Designing and deciding PCB tool(Prashant, Vatsal)'''
*'''Finalizing GPS module by doing some research (Vidushi)'''
*'''Finalize and order LCD (Aakash, Vidushi)'''
*'''Finalize Motor and Order it (Vatsal)'''
*'''Environmental setup of Android (Saumil, Akshata)'''
|| Completed Completed Completed Completed Completed Completed 
|-
| '''4''' || '''20 March 2019'''|| '''26 March 2019'''||
*'''Understand DBC and implement the DBC file compatible with all the controllers.'''
*'''Test motor driving in different situations, begin to listen to CAN for controls.'''
*'''Establish communication across all the CAN controllers over CAN bus based on the DBC file.'''
*'''Verify the power-up interactions and configurations between Master and the other controllers.'''
*'''03/26/2019 DBC File'''
*'''03/26/2019 DEMO: CAN communication between controllers.'''
|| Completed Completed Completed Completed Completed Completed 
|-
| '''5''' || '''27 March 2019'''|| '''09 April 2019'''||
*'''Check and Resolve power issue for RC Car.'''
*'''Finalize high-level system block diagram and control scheme.'''
*'''Circuit Simulation in Diptrace Tool.'''
*'''PCB Layout Design in Diptrace Tool.'''
*'''Finalize Components placement on PCB.'''
*'''Establish a connection over Bluetooth and Android app.'''
*'''Establish a communication between Bluetooth devices.'''
*'''Interfacing of ultrasonic sensors to the SJOne board and check for basic functionality.'''
*'''Interface and get the reading of Lidar sensor with SJOne over UART.'''
*'''Chalk out the Message IDs based on the priority of the messages and the data to be sent across nodes.'''
*'''Interface of Servo & DC motor to the SJOne board and check for basic functionality.'''
*'''Interface Compass module with SJOne board using I2C serial bus.'''
*'''Interface bluetooth HC-05 module with SJOne board using serial Communication.'''
*'''Configure bluetooth HC-05 module name as Tech Savy using HC-05 Communication Mode.'''
*'''Explore UI designing of LCD.'''
*'''Finish motor controller API. Test motor driving in different situations, begin to listen to CAN for controls.'''
*'''Add a TextView for displaying the Bluetooth connection status in Android App.'''
|| Completed Completed Completed Completed Completed Completed Completed Completed Completed Completed Completed Completed Completed Completed Completed Completed Completed 
|-
| '''6''' || '''10 April 2019'''|| '''16 April 2019'''||
*'''Parse data of Lidar Sensor depending on distance and angle and send it to master using dbc.'''
*'''Implement basic obstacle avoidance algorithm based on sensor data and test the same.'''
*'''Continue testing motor driver via commands from CAN bus.'''
*'''Build in speed steps to reverse motor for reverse to work correctly.'''
*'''Mount all the sensors and test for any dead band and modify their positions for maximum coverage.'''
*'''Integrate the fusion of LIDAR and Ultrasound sensor to get overall feedback from all the directions.'''
*'''Develop algorithm to avoid obstacles and plan the car's further navigation path.'''
*'''Complete final prototype of the obstacle avoidance feature.'''
*'''Calibrate Compass Module. Develop code for Compass module communication over CAN.'''
*'''16 April 2019 DEMO: Motors driven by wheel feedback and sensors, Basic obstacle avoidance.'''
*'''Final Wiki Schedule.'''
||Completed Completed Completed Completed Completed Completed Completed Completed Completed Completed Completed 
|-
| '''7''' || '''17 April 2019'''|| '''23 April 2019'''||
*'''Configure GPS device baud rate and interface it with SJOne board using UART.'''
*'''Send and receive current location, destination and checkpoint coordinates to and from App and Geo module via BRIDGE.'''
*'''Calibrate sensors readings and work on filtering algorithm with Master & Sensor'''
*'''Begin work on LCD to show vehicle live status(speed, fuel-status, obstacles, distance to destination etc.) in a GUI.'''
*'''Finish implementing speed control on motor (to make sure requested speed is met based on RPM read).'''
*'''Work on Car reversing using Motor Controllers.'''
*'''Integrate all modules with the Master to test the data flow.'''
*'''Validation & Verification of obstacle avoidance, steering logic with rear sensor inputs and reversing.'''
*'''Start incorporating GEO Controller information to Master module Steering logic.'''
*'''Decide, implement and test data exchange between Geo Controller and BRIDGE.'''
*'''Calculate and send simple bearing angle and destination status on CAN to figure out initial challenges.'''
*'''Add a Google Map for setting the car's destination.'''
*'''Send car location to app and check points received to Geo module.'''
*'''Verify the stringent requirement of Start-up Sync, Periodic heart-beat messages.'''
*'''Update Wiki Schedule with Test Reports.'''
|| Completed Completed Completed Completed Completed Completed Completed Completed Completed Completed Completed Completed In Progress Completed Completed 
|-
| '''8''' || '''24 April 2019'''|| '''30 April 2019'''||
*'''Testing & Validation of the LCD UI and display run time vehicle status and looking forward for feedback from team if any.'''
*'''Improve & Validate Navigation logic with multiple checkpoints, bearing angle and destination information.'''
*'''Identify and mitigate GPS locking, Location Accuracy and Number of Satellite-In-View coming.'''
*'''Validate Accuracy of Compass Calibration with iPhone Compass.'''
*'''Determine and add DBC Changes and finalized.'''
*'''Implement the steering logic with bearing angle and status provided by GEO-Module.'''
*'''Consistently Communicate current car location to App, get check points from App and relay them to Geo module.'''
*'''Send additional vehicle status information from can bus to the App for display.'''
*'''Send the request to Google for getting the checkpoints(use the Google Maps Directions API).'''
*'''Field test and check for obvious issues in obstacle avoidance, navigation, maintaining speed (up/down hill).'''
*'''Provide feed backs to each team on identified short comings.'''
*'''Update Wiki with new details and information.'''
*'''DEMO: GPS driving'''
|| Completed Completed Completed Completed Completed Completed Completed Completed Completed Completed Completed Completed Completed 
|-
| '''9''' || '''1 May 2019'''|| '''7 May 2019'''||
*'''FIELD TESTING - CRITICAL WEEK '''
*'''Implement turning indicators, break lights and head light.'''
*'''Check for Corner cases for steering logic under various conditions and locations.'''
*'''Analyse field test results for GPS and CMPS and work on it if required.'''
*'''Test the accuracy of check-points from the Blue-tooth controller, location data from the Geo-controller sensor and Navigation Algorithm.'''
*'''Check overall robustness of the complete system.'''
*'''Establish complete connection on PCB'''
*'''Update wiki with details.'''
||Completed Completed Completed Completed Completed Completed Completed 
|-
| '''10''' || '''8 May 2019'''|| '''21 May 2019'''||
*'''All hands on testing and final bug fixes.'''
*'''Check for tuning or calibration of modules if required.'''
*'''Complete end-to-end testing for various scenarios and conditions.'''
*'''Create the semester long project activity video and upload to YouTube.'''
*'''Update and finalize wiki.'''
||Completed Completed Completed Completed Completed 
|-
| '''11''' || '''22 May 2019'''|| ||
*'''DEMO: Final Project '''
*'''SUBMISSION: Final Project Wiki'''
||Completed Completed 
|}

== '''BILL OF MATERIALS (GENERAL PARTS)''' ==

{| class="wikitable"
|-
! scope="col" style="text-align: left;" style="background:#7acee2;" | PART NAME 

! scope="col" style="text-align: left;" style="background:#7acee2;" | 
PART MODEL & SOURCE 
! scope="col" style="text-align: left;" style="background:#7acee2;" | 
QUANTITY 
! scope="col" style="text-align: left;" style="background:#7acee2;" | 
COST PER UNIT (USD) 
|-
|
* '''Micro-Controller Eval-Boards'''
|
* LPC 1758 '''(Purchased from Preet Kang)
|
* 5
|
* 80.00

|-
|
* '''RC Car'''
|
* [https://www.amazon.com/Traxxas-Slash-Course-2-4GHZ-Vehicle/dp/B01DU474B0/ref=sr_1_3?ie=UTF8&qid=1474747759&sr=8-3&keywords=Traxxas+1%2F10+slash+2wd Traxxas 1/10 Slash 2WD RTR with 2.4GHz Radio]
|
* 1
|
* 205.99

|-
|
* '''Lithium-Ion Battery'''
|
* [https://www.amazon.com/Traxxas-7600mAh-7-4V-2-Cell-Battery/dp/B00S1R0VEY/ref=sr_1_7?s=toys-and-games&ie=UTF8&qid=1474748332&sr=1-7&keywords=traxxas+battery Traxxas 7600mAh 7.4V 2-Cell 25C LiPo Battery]
|
* 1
|
* 74.95

|-
|
* '''Lithium-Ion Battery 2'''
|
* [https://www.amazon.com/Traxxas-11-1V-5000mAh-3-Cell-Battery/dp/B07D691FPT Traxxas 2872X 5000mAh 11.1V 3S 25C LiPo Battery]
|
* 1
|
* 69.95

|-
|
* '''RC Car Battery Charger'''
|
* [https://www.amazon.com/Traxxas-2970-EZ-Peak-Charger-Identification/dp/B00OAFYLJC/ref=pd_bxgy_21_img_2?ie=UTF8&psc=1&refRID=JVX791WVV9Y8T9DW92KW Amazon Traxxas 2970 EZ-Peak Plus 4-Amp NiMH/LiPo Fast Charger]
|
* 1
|
* 49.95

|-
|
* '''Bluetooth Breakout Board'''
|
* [https://www.amazon.com/HC-05-Bluetooth-Pass-through-Wireless-Communication/dp/B01G9KSAF6/ref=sr_1_4?ie=UTF8&qid=1507077325&sr=8-4&keywords=arduino+bluetooth+hc-05 Bluetooth Module HC-05]
|
* 1
|
* 8.49

|-
|
* '''RC Car Display'''
|
* [http://www.4dsystems.com.au/product/uLCD_32PTU/ 4D systems 4D systems LCD Display]
|
* 1
|
* 79.00

|-
|
* '''Ultrasonic Sensors'''
|
* [http://www.robotshop.com/en/maxbotix-ez0-ultrasonic-ranger.html LV Maxsonar EZ0 & Ultrasonic sensors]
|
* 2
|
* 30.00

|-
|
* '''RP-LIDAR Sensor'''
|
* [https://www.amazon.com/RPLiDAR-A1M8-Degree-Laser-Scanner/dp/B07H7X3SFF/ref=sr_1_fkmrnull_1?crid=2FSUI76G4UA8K&keywords=rplidar+a1m8+-+360+degree+laser+scanner+development+kit&qid=1552764172&s=gateway&sprefix=RPlidar%2Caps%2C263&sr=8-1-fkmrnull LIDAR Sensor]
|
* 1
|
* 99.00

|-
|
* '''GPS Antenna'''
|
* [https://www.amazon.com/SaferCCTV-Coaxial-Pigtail-Connector-Transmitter/dp/B06WCZ9JPL/ref=sr_1_4?keywords=GPS+Antenna+PCIe&qid=1557263057&s=gateway&sr=8-4 Amazon]
|
* 1
|
* 5.00

|-
|
* '''CAN Transreceivers'''
|
* [http://www.microchip.com/samples/Default.aspx?DeviceFamily=MCP2551 Microchip Samples]
|
* 20
|
* FREE

|-
|
* '''Compass'''
|
* [https://www.dfrobot.com/product-1275.html DFRobot CMPS11 Compass]
|
* 2
|
* 30.00

|-
|
* '''RPM Sensor'''
|
* [https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM Amazon RPM Sensor]
|
* 1
|
* 10.00

|-
|
* '''GPS Breakout Board'''
|
* [https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM Amazon GPS Module]
|
* 1
|
* 43.00

|-
|
* '''PCB parts and other Miscellaneous parts'''
|
* Anchor Electronics and Digikey '''
|
* 1
|
* 130.00

|-
|
* '''PCB Fabrication'''
|
* [https://jlcpcb.com/quote JLCPCB]
|
* 5
|
* 29.53
|}

 

== '''Printed Circuit Board''' ==

=== Design And Architecture ===
We designed the custom PCB using DipTrace Software in which we implemented connections for all the controller modules(SJOne Board LPC1758) all communicating/sending data via CAN bus. The data is sent by individual sensors to the respective controllers. GPS and Compass are connected to Geographical Controller. RPM sensor, DC and Servo Motors are connected to Motor Controller. Ultrasonic and Lidar are connected to Sensor Controller. LCD is connected to Motor Controller. Bluetooth is connected to Bridge Controller. CAN Bus is implemented using CAN Transceivers MCP2551 terminated by 120Ohms; with PCAN for monitoring CAN Debug Messages and Data.

=== Power Section===
We implemented separate power modules for LIDAR and remaining modules of the PCB. The micro USB mini B supplies 5V to LIDAR Motor and Scanner (max current rating estimated @ 1A). Another power is supplied through USB 2.0 Type A connector with a rating of 5V@2A. Since GPS requires 3.3V, we have used a linear regulator REG1117-3.3. All the parts are through-hole components.

=== Fabrication ===
PCB was sent to fabrication to JLCPCB China which provided PCB with MOQ of 5 with the lead time of 1 week. We implemented 2 layers of PCB with most of the parts in top layer. We implemented rectangular header connector for SJOne boards, RPM sensor, DC & Servo Motor and GPS modules on the bottom layer.

=== Challenges ===
There were 2 iterations of this board. The first one was designed without validation and had problems with orientation of the SJOne board header & pin connections. We also need to change the header for LCD since it was having different pitch.This design lacked several necessary power connections and was limited by functionality. These problems were fixed in the 2nd iteration.
 

[[File:DipTrace1.jpg|1000x1200px|thumb|center|PCB Layout Design in DipTrace]]
[[File:Top_layer.png|500x600px|thumb|left|PCB Top Layer]]
[[File:Bottom_layer.png|500x600px|thumb|right|PCB Bottom Layer]]

=='''CAN Communication'''==
*As the DBC file shows, master is given the highest priority after bridge start/stop command message.
*All messages from every controller are send to Bridge and Motor as well along with Master, to display it on Android app and LCD Controller for debugging and testing.
*Every controller is also sending Initialization Debug messages over CAN, to verify it on BusMaster.
*1Hz task is used to check CAN_bus_off() condition, along with send heartbeat and debug message messages over can.
*As master is the major receiver of all the signals, it perform MIA handling of all necessary signals along with heartbeat as well.
*We have also used plenty of LEDs for confirming we get correct heartbeat and data.
*The code for master MIA initialization is as shown below,

const uint32_t BRIDGE_NODE__MIA_MS = 3000;
const BRIDGE_NODE_t BRIDGE_NODE__MIA_MSG = { 0, {0} };
const uint32_t SENSOR_NODE__MIA_MS = 3000;
const SENSOR_NODE_t SENSOR_NODE__MIA_MSG = { 0 };
const uint32_t GPS_LOCATION__MIA_MS = 3000;
const GPS_LOCATION_t GPS_LOCATION__MIA_MSG = { 37.3686485, -121.9153289, {0} };
const uint32_t COMPASS__MIA_MS = 3000;
const COMPASS_t COMPASS__MIA_MSG = { 37.3686485, -121.9153289, 0.0, {0} };
const uint32_t SENSOR_HEARTBEAT__MIA_MS = 3000;
const SENSOR_HEARTBEAT_t SENSOR_HEARTBEAT__MIA_MSG = {0, {0}};
const uint32_t MOTOR_HEARTBEAT__MIA_MS = 3000;
const MOTOR_HEARTBEAT_t MOTOR_HEARTBEAT__MIA_MSG = {0, {0}};
const uint32_t GPS_HEARTBEAT__MIA_MS = 3000;
const GPS_HEARTBEAT_t GPS_HEARTBEAT__MIA_MSG = {0, {0}};
const uint32_t BRIDGE_HEARTBEAT__MIA_MS = 3000;
const BRIDGE_HEARTBEAT_t BRIDGE_HEARTBEAT__MIA_MSG = {0, {0}};

==Hardware Design==
The CAN bus hardware implementation between all the controller module for this project is shown below. It is necessary to terminate the CAN bus at 120 Ohms to prevent any signal reflections.
[[File:CAN_Hardware.jpg|1000x1200px|thumb|center|PCB Layout Design in DipTrace]]

We have implemented some LEDs for indicating the heartbeat signals sent by the master, sensor readings and motor movements. Below is the table explaining the LEDs in PCBs along with the color, pin and signal description

{| class="wikitable"
|-
! scope="col" style="text-align: left;" style="background:#7acee2;" | 
LED DESIGNATION
! scope="col" style="text-align: left;" style="background:#7acee2;" | 
GPIO PINS
! scope="col" style="text-align: left;" style="background:#7acee2;" | 
DESCRIPTION 
! scope="col" style="text-align: left;" style="background:#7acee2;" | 
COLOR 
|-
|
* '''D1'''
|VCC and GND
|POWER
|RED
|-
|
* '''D2 MOTOR'''
|P2.5 and VCC
|RPM
|RED
|-
|
* '''D3 MOTOR'''
|P0.29
|Motor Heartbeat
|Yellow
|-
|
* '''D4 MOTOR'''
|P0.30
|DC Motor
|Blue
|-
|
* '''D5 MOTOR'''
|P1.19
|Servo Motor
|Green
|-
|
* '''D6 BRIDGE'''
|P0.29
|Bridge Heartbeat
|Red
|-
|
* '''D7 BRIDGE'''
|P0.30
|DC Motor
|BLUE
|-
|
* '''D8 GPS'''
|P0.30
|Geographical FIX
|BLUE
|-
|
* '''D9 GPS'''
|P0.29
|Geographical Heartbeat
|Yellow
|-
|
* '''D10 GPS'''
|P1.19
|Compass Data
|Green
|-
|
* '''D11 SENSOR'''
| P0.29
| Sensor Heartbeat
| Green
|-
|
* '''D12 SENSOR'''
| P0.30
| Left Obstacle
| Yellow
|-
|
* '''D13 SENSOR'''
| P1.19
| Right Obstacle
| Blue
|-
|
* '''D14 SENSOR'''
| P1.20
| Front Obstacle
| Green
|-
|
* '''D15 SENSOR'''
| P1.19
| Right Obstacle
| Blue
|-
|
* '''D16 MASTER'''
| P0.29
| Sensor Heartbeat
| Red
|-
|
* '''D17 MASTER'''
| P0.30
| Motor Heartbeat
| Green
|-
|
* '''D18 MASTER'''
| P1.19
| Bridge Heartbeat
| Yellow
|-
|
* '''D19 MASTER'''
| P1.20
| Geographical Heartbeat
| Blue
|-
 

=='''DBC File'''==
A Link to the DBC file that defines the CAN communication of the system is as follows:
[https://gitlab.com/tech-savycmpe243/cmpe243_techsavy_rc_car/blob/master/PROJ_DBC_File/243_techSavvy.dbc DBC link on GitLab]
 

DBC is a format that enables fewer hassles while developing code to either interpret data received or send data over the CAN bus. This project used DBC effectively.

Shown below is the DBC implementation for this project.
<pre>
VERSION ""

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

BS_:

BU_: MASTER BRIDGE MOTOR SENSOR GPS DBG

BO_ 103 BRIDGE_NODE: 1 BRIDGE
SG_ BRIDGE_START_cmd : 0|1@1+ (1,0) [0|1] "" MASTER,MOTOR

BO_ 104 CAR_CONTROL: 4 MASTER
SG_ MOTOR_DRIVE_cmd : 0|2@1+ (1,0) [0|0] "" MOTOR,BRIDGE
SG_ MOTOR_STEER_cmd : 2|15@1+ (0.1,-90.0) [-90|90] "" MOTOR,BRIDGE
SG_ MOTOR_kph : 17|12@1+ (0.01,0) [0.00|20.00] "kph" MOTOR,BRIDGE

BO_ 105 SENSOR_NODE: 5 SENSOR
SG_ SENSOR_FRONT_cm : 0|10@1+ (1,0) [0|645] "cm" MASTER,MOTOR,BRIDGE
SG_ LIDAR_Obstacle_FRONT : 10|3@1+ (1,0) [0|0] "" MASTER,MOTOR,BRIDGE
SG_ LIDAR_Obstacle_RIGHT : 13|3@1+ (1,0) [0|0] "" MASTER,MOTOR,BRIDGE
SG_ LIDAR_Obstacle_LEFT : 16|3@1+ (1,0) [0|0] "" MASTER,MOTOR,BRIDGE
SG_ LIDAR_Obstacle_BACK : 19|3@1+ (1,0) [0|0] "" MASTER,MOTOR,BRIDGE
SG_ LIDAR_Obstacle_BACK_RIGHT : 22|3@1+ (1,0) [0|0] "" MASTER,MOTOR,BRIDGE
SG_ LIDAR_Obstacle_BACK_LEFT : 25|3@1+ (1,0) [0|0] "" MASTER,MOTOR,BRIDGE

BO_ 106 MOTOR_NODE: 2 MOTOR
SG_ MOTOR_SPEED_kph : 0|12@1+ (0.01,0) [0.00|20.00] "kph" MASTER,BRIDGE

BO_ 107 BRIDGE_CHECKPOINTS: 8 BRIDGE
SG_ CHECKPOINT_LAT_deg : 0|28@1+ (0.000001,-90.000000) [-90|90] "Degrees" MASTER,GPS,MOTOR
SG_ CHECKPOINT_LONG_deg : 28|29@1+ (0.000001,-180.000000) [-180|180] "Degrees" MASTER,GPS,MOTOR

BO_ 108 GPS_LOCATION: 8 GPS
SG_ CURRENT_LAT_deg : 0|28@1+ (0.000001,-90.000000) [-90|90] "Degrees" MASTER,BRIDGE,MOTOR
SG_ CURRENT_LONG_deg : 28|29@1+ (0.000001,-180.000000) [-180|180] "Degrees" MASTER,BRIDGE,MOTOR

BO_ 109 COMPASS: 8 GPS
SG_ CMP_HEADING_deg : 0|12@1+ (0.1,0) [0|359.9] "Degrees" MASTER,BRIDGE,MOTOR
SG_ CMP_BEARING_deg : 12|12@1+ (0.1,0) [0|359.9] "Degrees" MASTER,BRIDGE,MOTOR
SG_ CMP_DISTANCE_meters : 24|17@1+ (0.01,0) [0|0] "Meters" MASTER,MOTOR,BRIDGE

BO_ 110 MASTER_HEARTBEAT: 1 MASTER
SG_ MASTER_hbt : 0|1@1+ (1,0) [0|1] "" SENSOR,MOTOR,BRIDGE,GPS

BO_ 111 SENSOR_HEARTBEAT: 1 SENSOR
SG_ SENSOR_hbt : 0|1@1+ (1,0) [0|1] "" MASTER

BO_ 112 MOTOR_HEARTBEAT: 1 MOTOR
SG_ MOTOR_hbt : 0|1@1+ (1,0) [0|1] "" MASTER

BO_ 113 GPS_HEARTBEAT: 1 GPS
SG_ GPS_hbt : 0|1@1+ (1,0) [0|1] "" MASTER

BO_ 114 BRIDGE_HEARTBEAT: 1 BRIDGE
SG_ BRIDGE_hbt : 0|1@1+ (1,0) [0|1] "" MASTER

BO_ 115 SENSOR_DEBUG: 1 SENSOR
SG_ IO_DEBUG_CAN_init : 0|1@1+ (1,0) [0|0] "" DBG
SG_ IO_DEBUG_sensor_init : 1|1@1+ (1,0) [0|0] "" DBG
SG_ IO_DEBUG_CAN_TX : 2|1@1+ (1,0) [0|0] "" DBG
SG_ IO_DEBUG_bus_off : 3|1@1+ (1,0) [0|0] "" DBG

BO_ 116 MOTOR_DEBUG: 2 MOTOR
SG_ IO_DEBUG_CAN_init : 0|1@1+ (1,0) [0|0] "" DBG
SG_ IO_DEBUG_bus_off : 1|1@1+ (1,0) [0|0] "" DBG
SG_ IO_DEBUG_RPM_kph : 2|12@1+ (0.01,0) [0.00|20.00] "kph" DBG

BO_ 117 MASTER_DEBUG: 1 MASTER
SG_ IO_DEBUG_CAN_init : 0|1@1+ (1,0) [0|0] "" DBG
SG_ IO_DEBUG_bus_off : 1|1@1+ (1,0) [0|0] "" DBG
SG_ IO_DEBUG_drive_mode : 2|1@1+ (1,0) [0|0] "" DBG
SG_ IO_DEBUG_HBT_FROM_ALL_CONTR : 3|1@1+ (1,0) [0|0] "" DBG

BO_ 118 GPS_DEBUG: 1 GPS
SG_ IO_DEBUG_CAN_init : 0|1@1+ (1,0) [0|0] "" DBG
SG_ IO_DEBUG_HBT_Transmit : 1|1@1+ (1,0) [0|0] "" DBG
SG_ IO_DEBUG_bus_off : 2|1@1+ (1,0) [0|0] "" DBG
SG_ IO_DEBUG_GPS_rx : 3|1@1+ (1,0) [0|0] "" DBG
SG_ IO_DEBUG_GPS_Fix : 4|1@1+ (1,0) [0|0] "" DBG
SG_ IO_DEBUG_Compass_Rx : 5|1@1+ (1,0) [0|0] "" DBG

BO_ 119 BRIDGE_DEBUG: 1 BRIDGE
SG_ IO_DEBUG_CAN_init : 0|1@1+ (1,0) [0|0] "" DBG
SG_ IO_DEBUG_HBT_Transmit : 1|1@1+ (1,0) [0|0] "" DBG
SG_ IO_DEBUG_bus_off : 2|1@1+ (1,0) [0|0] "" DBG
SG_ IO_DEBUG_Connected : 3|1@1+ (1,0) [0|0] "" DBG
SG_ IO_DEBUG_Bridge_rx : 4|1@1+ (1,0) [0|0] "" DBG

CM_ BU_ MASTER "The master controller driving the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";
CM_ BU_ BRIDGE "The bridge controller of the car";
CM_ BU_ GPS "The gps controller of the car";
CM_ BU_ DBG "The debug node of the car";
CM_ BO_ 100 "Sync message used to synchronize the controllers";

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

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

BA_ "GenMsgCycleTime" BO_ 103 100;
BA_ "GenMsgCycleTime" BO_ 104 100;
BA_ "GenMsgCycleTime" BO_ 105 100;
BA_ "GenMsgCycleTime" BO_ 106 100;
BA_ "GenMsgCycleTime" BO_ 107 100;
BA_ "GenMsgCycleTime" BO_ 108 100;
BA_ "GenMsgCycleTime" BO_ 109 100;
BA_ "GenMsgCycleTime" BO_ 110 100;
BA_ "GenMsgCycleTime" BO_ 111 100;
BA_ "GenMsgCycleTime" BO_ 112 100;
BA_ "GenMsgCycleTime" BO_ 113 100;
BA_ "GenMsgCycleTime" BO_ 114 100;
BA_ "GenMsgCycleTime" BO_ 115 100;
BA_ "GenMsgCycleTime" BO_ 116 100;
BA_ "GenMsgCycleTime" BO_ 117 100;
BA_ "FieldType" SG_ 104 MOTOR_DRIVE_cmd "MOTOR_DRIVE_cmd";

VAL_ 104 MOTOR_DRIVE_cmd 2 "MOTOR_STOP" 1 "MOTOR_REV" 0 "MOTOR_FORWARD" ;

</pre>

A screenshot of the Bus Master Application is as shown below:
[[File:Busmaster.jpg|800px|thumb|center|]]
<HR>
 

=='''3D printing models''' ==
We used a 3D mount model to mount the ultrasonic sensor and compass. After testing the ultrasonic sensor at different angles we noticed that best results are when sensors are mounted at 70 degrees with respect to the ground. Most important thing to consider was the mount should be able to adjust tilt of the sensors since we were receiving lot of reflection from the ground. So in order to satisfy that requirement mount is constructed from two parts, the stand and part that holds the sensor what gave us freedom to test sensors positioning. We used the 3D mount design from Thingiverse.

Since we needed to keep the Compass sensor away from DC Motor's interference, we decided to keep the compass at certain height above the PCB. So we used 3D printing to print the support plate with the mounting holes of same dimension as M3X10 screw standoffs.

[[File:Ultrasonic_mount.jpg|300px|thumb|left|Ultrasonic Sensor Mount]]
[[File:Actual_mount.jpg|160px|thumb|right|Actual Mount]]

[[File:Compass_mount.JPG|280px|thumb|center|Compass Mount]]

=='''Sensor Node'''==
We used 2 sensor modules to achieve accurate and reliable obstacle avoidance system. 
'''1. Lidar''' - Main controller to detect obstacle. Giving 360-degree view with a range up to 6 meters in distance. 
*RPLidar works on a mechanism known as laser triangulation ranging principle. The system measures distance data in more than 2000 times’ per second and with high-resolution distance output. RPLIDAR emits modulated infrared laser signal and the laser signal is then reflected by the object to be detected. The returning signal is sampled by vision acquisition system in RPLIDAR A1 and the DSP embedded in RPLIDAR starts processing the sample data and output distance value and angle value between object and RPLIDAR A1 through the communication interface. 
[[File:Lidar_RPLidar_working_schematic.png|500x900px|thumb|center|Lidar Working Schematic]]

'''2. Ultrasonic Sensor (Maxbotix LV-MaxSonar-EZ0)''' - One Ultrasonic sensor with a maximum range of 600 cm was used to detect very small objects at the front that Lidar might miss because of it's leveled placement. 
[[File:ultrasonicbeam.png|100px|thumb|right|ultrasonic beam]]
*Ultrasonic sensor uses a high-frequency beam to detect an object. It first throws light and reads the time taken for light to receive back, depending on the time calculated, it identifies the obstacle. It calibrates after it's first to read cycle, then it can continuously read data of light. The beam depending on the range is shown in figure. 

====Sensor Node Code====
[https://gitlab.com/tech-savycmpe243/cmpe243_techsavy_rc_car/tree/master/Sensor_Controller_Module GitLab link to Sensor Code]

=== Hardware Design ===
*The Lidar is communicating with SJOne board through UART, we have used UART 2 here as shown in Pin config below. 
*Ultrasonic Sensor is simple Interrupt based, hence it connected through GPIO pins of SJOne board as shown in diagram. 

[[File:TechSavy_Lidar_pincon.png|500x900px|thumb|center|Sensor Pin connection]]

*Figure shows the usage of 4 LEDS and LCD display to notify us the position of obstacle. 

[[File:techsavy_lidar_led.jpg|300px|thumb|left|LED indication]]
[[File:TechSavy_sensor_lcd_screen.jpeg|300px|thumb|center|LCD screen showing the value of track of obstacle at respective direction]]

====Implementation====
====='''Ultrasonic'''=====
LV Maxsonar ultrasonic sensor is used at the very front of the RC car to provide wide range sonar detection ranging from 0 to 645 cm. It supports LiDAR sensor to detect very small obstacles like stone that can hinder car from moving forward. so we have purposefully mounted it at a lower level than LiDAR.

====='''LiDAR'''=====
RPLidar works on UART. We have used UART 2 of SJOne Board to establish communication between them.

*Figure shows the several operation provided by RPLidar for better performance and reliable data. 
[[File: lidar_operation.png|700px|thumb|center| Various Operations of RPLidar]] 

'''Algorithm to establish communication through UART'''
* In order to start the scanning of Lidar, first send the 0X20 via <code>uart2.putchar(0x20)</code>. Before that, we can check the health status of RPLidar by sending 0x52. It waits for some time (timeout = 500ms), and if return status is not true throws error indicating Lidar is not initialized properly and hence it gets reset. 

* As soon as correct scan command is received by Lidar, it starts sending data frames continuously on UART. The frame consists of 5 bytes including the start bit, Angle, quality and distance, which are useful to identify the exact position of obstacle. 

[[File:RPLidar_data_frame.png|500px|thumb|center|]]

* This data is processed and divided into tracks of 25 cm each. 

* By looking at the track, we choose the sector value which depends on angle detected. Below figure shows the division of angle for respective sector value. 
[[File:TechSavy_Lidar_angle.png|700px|thumb|center|Figure shows the division of angles]]
* The obstacle information is sent to Master Node through CAN. 

=== Software Design ===
===='''Ultrasonic'''====
*It works with the help of interrupt.
* After configuring GPIO pins as RX and TX, set RX pin high.
* PW pin gets the input, identify the type of interrupt
**Rising edge interrupt.
**Falling edge interrupt
*Calculate distance to obstacle,
** <code>ultrasonic_data.distance = (stop_time - start_time)/147; </code>

===='''LiDAR'''====
Below diagram shows the code flow of sensor module. A separate task was used to send sensor data over CAN, which continuously sends data in while(1) loop.
[[File:TechSavy_Sensor_flowchart.png|770x770px|center|Sensor Flowchart]]

====CAN DBC Messages Send from Sensor====

BO_ 105 SENSOR_NODE: 5 SENSOR
SG_ SENSOR_FRONT_cm : 0|10@1+ (1,0) [0|645] "cm" MASTER,MOTOR,BRIDGE
SG_ LIDAR_Obstacle_FRONT : 10|3@1+ (1,0) [0|0] "" MASTER,MOTOR,BRIDGE
SG_ LIDAR_Obstacle_RIGHT : 13|3@1+ (1,0) [0|0] "" MASTER,MOTOR,BRIDGE
SG_ LIDAR_Obstacle_LEFT : 16|3@1+ (1,0) [0|0] "" MASTER,MOTOR,BRIDGE
SG_ LIDAR_Obstacle_BACK : 19|3@1+ (1,0) [0|0] "" MASTER,MOTOR,BRIDGE
SG_ LIDAR_Obstacle_BACK_RIGHT : 22|3@1+ (1,0) [0|0] "" MASTER,MOTOR,BRIDGE
SG_ LIDAR_Obstacle_BACK_LEFT : 25|3@1+ (1,0) [0|0] "" MASTER,MOTOR,BRIDGE

===='''LED Blinking signals for SENSOR CONTROLLER ON CAR'''====
* RED LED ON: MASTER HEARTBEAT STATUS on CAR
* BLUE LED ON: Obstacle detected at front of CAR
* Rightmost GREEN LED ON: Obstacle detected at right of CAR
* YELLOW LED ON: Obstacle detected at back of CAR
* Leftmost GREEN LED ON: Obstacle detected at left of CAR.

=== Technical Challenges ===
===='''Ultrasonic'''====
*When mounted initially on CAR, ultrasonic was giving sometimes faulty readings as it was detecting ground as and obstacle.
**We designed a 3D mount for it and adjusted it on such a angle that it gives perfect readings.
*Initialization issue: Sometimes on power-up we noticed that Ultrasonic sensor was giving faulty readings(it was getting stuck on some fixed value).
**After reading the datasheet accurately, I found that it calibrates itself during the first read cycle and so the obstacle should be at least 14 inches far from the sensor.
*Ultrasonic Failure - When the CAR got crashed, Ultrasonic sensor failed and started giving incorrect data.
**We replaced it's wired to get it working. 

===='''LiDAR'''====
* Identifying obstacle data and separating it.
** Initially I lost a lot of time in figuring out the data frame as it consists of quality, angle, distance and start bit.
** Dividing the frame bits appropriately and storing it separately in struct variables resolved the issue. Also after that depending on the angle, every 360 times data was fetched in a loop to cover each and every angle value.
* Task overrun because of receiving a large number of data continuously over UART.
** Used a separate task, that receives data continuously in a loop, i.e while(1).
** Instead of receiving whole data in a single frame, took data character by character in a for loop 360 times, to get the value of obstacle at each degree.
* Angle detection problem - When large angles were taken, for example, 30 degrees on the right, it was detecting nearer objects correctly but far objects were getting detected in some other range (for example in front instead of right) of angle because of angle spread. I divided the range into 10 degrees each and store it in the same variable to send it over CAN. For example, to get 30 degrees in right, 0-10,10-20 & 20-30 values are taken.
* Received variable initialization problem.
** I didn't initialize the character variable to get data from UART to 0 and hence it was taking garbage value. Thanks to Preet, at time of my code review he pointed out this problem and later I checked it with Unit Testing.
* Some bugs here and there in the code.
** I identified and resolved a few bugs after Unit testing the code.
* Delay in sending data because of large CAN buffer size.
** We were facing this issue with master, motor and sensor communication. The response time was slow as data was getting accumulated before sending because of large buffer size taken.

 

=='''Motor Controller'''==
Motor Controller is responsible to control the DC and Servo Motor, RPM Sensor measurements and LCD control. The motor control logic controls the steering and the speed of the vehicle using a servo and DC motor respectively based on the CAR_CONTROL_t CAN message from the master. It takes input from RPM sensor as a feedback for maintaining a constant speed and based on the RPM sensor reading, a PID loop calculates duty-cycle for PWM signal which are then given to DC motor. Based on other can messages from the sensor controller, geo controller and bridge controller, motor controller processes and communicates the information to the LCD by refreshing the data periodically in 10Hz function.

=== Hardware Design ===
The hardware interface details of '''MOTOR Module''' with SJOne board are given below:

[[ File: RPM Sensor, DC and Servo Motor Hardware Design.jpeg|600px|thumb|left|RPM Sensor, DC and Servo Motor Hardware Interfacing]]
[[ File: LCD.JPG |520px|thumb|center|LCD Hardware Connections]]

=== Hardware Interface ===

====Electronic Speed Controller (ESC)====
We made use of the Traxxas ESC XL-05 which comes with the RC car. ESC stands for Electronic Speed Control. It is used to control the DC motor using PWM signals from the controller. It powers up when we connect a LiPo or NiMH battery of 7.4v. The ESC has a dc-to-dc converter which converts 7.4v to 6v and provides it to DC motor. It can provide high current to the power hungry DC motors running at faster speeds. It has an LED and a button which is used for calibration and setting different modes for the car.

[[File:CMPE243 F17 nano ESC.jpg|220px|thumb|right|Traxxas ESC XL5]]

====DC Motor====

[[File:CMPE_S19_techsavy_dc.jpg‎|350px|thumb|right|Traxxas DC Motor]]
The DC motor is controlled using the ESC which get PWM pulses for controlling it. A PWM signal wire is connected to the microcontroller and the required current is provided by the LiPo battery and the ESC. Below table shows the LED functionality implemented in PCB for all the controllers.
{| class="wikitable"
|+ DC Motor Pin Connection
|-
! scope="col"| S.No
! scope="col"| Wires - DC Motor
! scope="col"| Description
|-
! scope="row"| 1.
| Positive Wire (already Connected)
| Positive Terminal
|-
! scope="row"| 2.
| Negative Wire (already Connected)
| Negative terminal
|-
|}

The DC motor is controlled using PWM at 100Hz.

{| class="wikitable"
|+ DC MOTOR Configuration
|-
! Operation !! Pulse Width Range(ms) !! Duty-cycle(%)
|-
| FORWARD || 1.51 - 2.00 || 15.1 - 20.0
|-
| STOP || 1.50 || 15.0
|-
| REVERSE || 1.00 - 1.49 || 10.0 - 14.9
|}

'''NOTE''': Before using the Traxxas ESC to give PWM signal to DC motor calibrate it by going to this website: 
:https://traxxas.com/support/Programming-Your-Traxxas-Electronic-Speed-Control 

:The ESC must be given a pulse of 1.5ms when we turn it on or else the DC motor won't respond to PWM pulses. 
:Step 1: Give 2.00ms on-time pulses when LED blinks red once. 
:Step 2: Give 1.50ms on-time pulses when LED blinks red twice. 
:Step 3: Give 1.00ms on-time pulses and the LED color changes from red to green showing that the calibration was successful. 

====Servo Motor====
[[File:CMPE243_F17_nano_servo.jpg ‎|200px|thumb|right|Traxxas Servo Motor]]
The direction the vehicle's front wheels turn is dependent on the servo motor in the vehicle. Based on various PWM signals, the servo steers the front wheels of the vehicle in the left and right direction. The servo has 3 wires of which one is for the PWM input signal whereas the other two are to power up the servo. We powered our servo motor using the 6v power supply from the battery elimination circuit present in the ESC so that a single switch to turn on and off both the servo and DC motor. PWM signals to control the servo is provided by the motor controller. Based on the PWM signal from the SJOne board, the
shaft shall be rotated to a certain degree left or right

{| class="wikitable"
|+ Servo Motor Pin Connection
|-
! scope="col"| S.No
! scope="col"| Wires - Servo Motor
! scope="col"| Function
|-
! scope="row"| 1.
| PWM connected to P2.1
| PWM signal from SJOne board
|-
! scope="row"| 2.
| VCC
| 6V power supply from ESC
|-
! scope="row"| 3.
| Ground
| Common ground to system
|-
|}

====RPM Sensor====
[[File:CMPE243_F17_nano_Speed_Sensor.jpg ‎|250px|thumb|right|Traxxas Speed Sensor]]
RPM sensor is used as a feedback element in the PID to maintain a constant speed of the vehicle. The RPM sensor mounts on the rear DC motor shaft compartment with a special assembly also provided by Traxxas. We make use of one magnet and we get one pulse on one wheel rotation The sensor works on the hall effect principle where it provides a current across its terminal when placed in a magnet's field. These pulses are read by the SJOne board and fed to the speed control algorithm. The RPM sensor has 3 wires, the white where are the output wire that provides the pulses to the SJone board and the other wires power the sensor.

=====Implementation=====
1. The idea is that every time the motor completes 1 whole revolution, it reaches very close to the sensor. And when the sensor detects the magnet nearby, it sends out a high pulse until the magnet moves away from it. Therefore, upon detecting the X number of a rising edge in Y seconds we can say that rpm was X revolutions/Y seconds. 
2. During our initial testing of RPM Sensor with SJOne board, we saw that regardless of whether we bring the magnet close to the sensor or not, the signal voltage was always high. After some trail and errors, we found out that the signal pin(white wire) had to be connected to the VCC(red wire) across a 1K resistor which can act as weak pull down when it detects the magnet. 

{| class="wikitable"
|+ Speed Sensor Pin Connection
|-
! scope="col"| S.No
! scope="col"| Wires - RPM Sensor
! scope="col"| Function
|-
! scope="row"| 1.
| Signal wire connected to P2.5
| GPIO that supplies pulses to controller
|-
! scope="row"| 2.
| VCC
| 6V power supply from ESC
|-
! scope="row"| 3.
| GND
| Common ground
|-
|}
 

==== uLCD32-PTU ====

uLCD32-PTU by 4D systems has a 3.2" TFT LCD Display module. The module comes with a display resolution of 240x320 pixels. 4D Systems provides a programming cable based on UART for burning the LCD code to the module. The project is burnt to a uSD card which is used for display during booting of the LCD. It is recommended that we use the programming adapter provided by 4D systems as it has a special reset button that can be used to download the built project to the LCD display.Once the LCD display was configured with different widgets and screens, the motor module was coded to display information in LCD through UART. Workshop4 IDE was used to program the GUI, and data was transmitted from the SJOne board through UART communication. The LCD displays the main menu screen with options of all the modules: Sensor, Motor, Bridge, GPS, Compass and MIA information.

These modules represent the page numbers of the display whose information can be found from the pre-processed data format of the LCD.This data format contains the following fields:
*The write command
*Type of the object
*Object ID
*MSB and LSB values to be displayed in the LED.
*The last pair of hex value is for checksum.

The following figure shows the programming cable and the pins used for uLCD32-PTU.
[[File:CMPE243_F17_nano_LCD-connection.JPG|thumb|300px|LCD connections|right]]
 
{| class="wikitable"
|+ LCD Pin Connection
|-
! scope="col"| S.No
! scope="col"| Wires - LCD interface
! scope="col"| Function
|-
! scope="row"| 1.
| TX
| Data Transmission connected to UART RX of SJ1 board
|-
! scope="row"| 2.
| RX
| Data Reception connected to UART TX of SJ1 board
|-
! scope="row"| 2.
| VCC
| Input 5v supply
|-
! scope="row"| 3.
| GND
| Common ground
|-
! scope="row"| 4.
| RES
| Reset Pulse(Not Required for our project)
|-
|}

=== Software Design ===
The dc motor and servo motor operation is fundamentally based on PWM (Pulse Width Modulation). We set the PWM frequency to 100Hz for both dc and servo motor. 

Pseudo code for initializing PWM to 100Hz. 
PWM *motor_control; //pointer object defined globally
PWM *servo_control;
void init_pwm(long unsigned int freq) {
motor_control = new PWM(PWM::pwm1, freq); // using PWM constructor to initialize the PWM 2.0 pin to desired frequency
servo_control = new PWM(PWM::pwm2, freq);
}

====DC Motor====
The DC motor is connected to pin P2.0 on SJONE board. The DC motor is commanded every 100ms to change or maintain its speed or direction(FORWARD, REVERSE and STOP). A switch case is used to check the command that we are receiving over CAN bus from master.

Pseudo code for dc motor and speed control
float speed = get_speed();
float _error = calculate_error_PID(drive_forward->MOTOR_mps, speed, &dc_motor);
*PWM_percent += _error
set_pwm_value(motor_1, *PWM_percent);

====Servo Motor====
The Servo motor is connected to pin P2.1 on SJONE board. The servo motor is commanded every 10ms to change or maintain its angle between 0 and 180 degrees. We receive angle in the range of -90(full left), 0(neutral) and +90(full right) from master. The calculate PWM_duty_cycle_servo function maps the angle received from master to PWM signal and rotates the servo motor accordingly.

Pseudo code for servo motor and angle calculation
on_time = 10 + ((servo->MOTOR_STEER_cmd + 90) * (10/180));
set_pwm_value(servo_2, on_time);

====RPM Sensor====
The RPM sensor is connected to pin P2.6 of SJONE board. When the wheel rotates once we get one pulse. We make use of interrupt to register these pulses in a 400ms time frame and then calculate the speed in m/s based on the formula:
speed_m_per_sec = (circumference * rotation_per_sec) / (constant);
After every 400ms we reset the pulse counter. We have an ISR which increments these pulses.
void eint3_handler(void){
pulse++;
}

====LED Blinking signals for MOTOR CONTROLLER====
*RED LED ON: MASTER HEARTBEAT STATUS on CAR
*BLUE LED ON: Car is moving in reverse direction
*YELLOW LED ON: Car is stopped
*GREEN LED ON: Car is moving in forward direction

====LCD Software Flow Chart====
[[File:CMPE_243_TechSavy_LCD_Refresh.JPG|450px|thumb|center|LCD Software Flowchart: 1Hz Task]]

====Programming SJONE Board for LCD Display====
*As raw data often cannot be displayed on the LCD directly, the values to be displayed had to be converted to appropriate byte-sized values.
*Communication with SJOne board was established at the baud rate of 115200 bps.
*Commands for writing data and reading acknowledgment for various gauges were coded in the SJ1 board.

====Creating a project using Workshop 4 IDE and programming the LCD display====
* After finalizing the design of the LCD's layout, a genie project was created using Workshop 4.
* The layout was split into different forms (pages) and appropriate buttons and gauges were added for display.
* uLCD-32PTU was programmed with the help of programming cable provided by 4D systems.

The steps taken for interfacing the LCD display with the SJONE board is shown on the right:

Each of the reading is considered as a object with the object type ID and object number. Below are the list of objects used for lcd.
#define GPS_DEST_LATITUDE_OBJ 0
#define GPS_DEST_LONGITUDE_OBJ 1
#define GPS_CURRENT_LATITUDE_OBJ 2
#define GPS_CURRENT_LONGITUDE_OBJ 3
#define GPS_HEADING_OBJ 13
#define GPS_BEARING_OBJ 14
#define GPS_DISTANCE_OBJ 3
#define MOTOR_SPEED_MS_OBJ 8
#define MOTOR_PWM_OBJ 12
#define MOTOR_RPM_OBJ 4
#define MOTOR_TURNING_ANGLE_OBJ 9
#define MOTOR_DISTANCE_COVERED_OBJ 10
#define MOTOR_DISTANCE_LEFT_OBJ 11

So our approach was to send a LCDquery at 1Hz task using the below function.
void lcd_screen_query(void)
{
char comm[] = {0, 0x0a, 0, 0x0a};
for (int i = 0; i < (int)sizeof(comm); i++)
{
uart3_put_char(comm[i], 0);
}
}

This query sends a a array of character to LCD and LCD acknowledges it and sends the pre-formated data to the controller using lcd_receive() called at every 10Hz. The receive() will contain the page number(lcd_screen) based on the screen it is currently into and prints the data corresponding to that screen i.e. GPS screen will call GPS_print function to print the GPS values.

void lcd_print()
{
switch (lcd_screen)
{
case menu:
lcd_print_menu_screen();
break;
case bridge:
lcd_print_bridge_screen();
break;
case gps:
lcd_print_gps_screen();
break;
case sensor:
lcd_print_sensor_screen();
break;
case motor:
lcd_print_motor_screen();
break;
case home:
lcd_print_home_screen();
break;
case mia:
lcd_print_mia_screen();
break;
case compass:
lcd_print_compass_screen();
break;
default:
break;
}
}

=='''LCD Screens'''==
{|
|[[File:screen8.PNG|thumb|220px|left|Main Screen]]
|[[File:screen1.PNG|thumb|220px|none|Module Selection Screen]]
|[[File:screen5.PNG|thumb|220px|right|MOTOR Screen]]
|[[File:screen4.PNG|thumb|220px|none|Sensors Screen]]
|}

 

{|
|[[File:screen6.PNG|thumb|220px|left|MID Status Screen]]
|[[File:screen7.PNG|thumb|220px|none|GPS Screen]]
|[[File:screen3.PNG|thumb|220px|right|Compass Screen]]
|[[File:screen2.PNG|thumb|220px|none|Bluetooth Screen]]
|}

 

==Flow charts==
{|
|[[ File: DC_motor_control.jpg|500px|frameless|right]]
|
|[[ File: Servo_motor_control.jpeg|300px|frameless|center]]
|
|[[ File: Speed_calc.jpg|270px|frameless|left]]
|}
 

<div align="center">'''DC motor speed and direction control using RPM sensor, Servo motor control and Speed calculator flow-chart'''</div>

=== Technical Challenges ===

'''PWM frequency setting problem''' 
:The PWM frequency won't set if we were making use of global objects directly using the SJONE PWM drivers. We verified using logic analyzer that our frequency was getting set to 1.19KHz instead of 100Hz. 
PWM motor_control(PWM::pwm1, freq);
PWM servo_control(PWM::pwm2, freq);
:'''Solution:''' After trying out many things we made use of global pointer objects to solve the problem. 
PWM *motor_control; //pointer object defined globally
PWM *servo_control;
void init_pwm(long unsigned int freq) {
motor_control = new PWM(PWM::pwm1, freq); // using PWM constructor to initialize the PWM 2.0 pin to desired frequency
servo_control = new PWM(PWM::pwm2, freq);
}

'''DC motor shooting randomly''' 
: When we were testing our DC motor, we found that our dc motor would shoot randomly in forward and reverse direction when using GPP board. We checked our code and the entire wiring but were not able to fix it. 
:'''Solution:''' When our PCB arrived we tested the DC motor on it and it worked fine. One suggestion would be to use the PCB as soon as possible as it won't waste your time on debugging unnecessary problems.

'''PID Calibration for uphill and downhill''' 
: It uses an extensive amount of time to get the PID loop working which gives proper error values which maneuvers the car without stopping on uphill and controls speed during the downhill.
: '''Solution:'''You should start using PID for maneuvering uphill and downhill conditions from the beginning.

'''LCD Refreshing''' 
: During testing the data received in LCD, we noticed that LCD was not getting refreshed quickly i.e even though PCAN dongle was updating data quickly but LCD was showing the data after a few seconds. At one point, the LCD stopped updating data.
: '''Solution:'''We used snprintf() for GPS and Sensor values.For Compass and Motor, we implemented MSB and LSB approach where lower 8 bits of data(int) was stored in LSB and upper 8 bits in MSB, followed by our custom display function lcd_put_comm() which converted the data to the pre-formatted data and displayed data over UART using uart_put_char(). Below is an example
char msb,lsb = 0;
int local_heading = gps_bearing * 100;
lsb = (char)((char) local_heading & 0xff);
msb = (char)((char) (local_heading >> 8) & 0xff);
lcd_put_comm(WRITE_OBJ, LED_DIGITS, GPS_HEADING_OBJ, msb, lsb);

 

=='''Geographical Controller'''==

Geographical Controller is one the most important controller in the autonomous car which helps it to navigate to its destination. This modules continuously update the position and orientation of the car with respect to geographical north and send the data to Master, Motor and Android controller boards. We are using the Adafruit Ultimate GPS module and CMPS11.

* GEO CONTROLLER Git Link: [https://gitlab.com/tech-savycmpe243/cmpe243_techsavy_rc_car/tree/master/Geographical_Controller_Module]

=== Hardware Design ===

The hardware interface details of '''GPS and Compass Module''' with SJOne board are given below:

[[ File: CmpE243_TechSavy_GEO_Controller.jpg|679px|thumb|centre||GPS & CMPS11 Module Hardware Interfacing]]

 

* '''LED Blinking signals for GEO CONTROLLER ON CAR'''
* RED LED ON: MASTER HEARTBEAT STATUS on CAR
* BLUE LED ON: Shows GPS FIX STATUS on CAR
* GREEN LED ON: COMPASS Data Indication

'''GPS'''

* '''GPS PinOut'''
* VCC: 3.3V Power
* GND: Ground
* TXD: Serial Transmit pin connected to RXD2 of SJOne board
* RXD: Serial Receive pin connected to TXD2 of SJOne board
* FIX: States if GPS is fixed not

[[ File: Gps Dump.png|700px|thumb|centre|| GPRMC NMEA DATA]]

 

GPS is a global navigation satellite system that provides geolocation 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.

The GPS module used in this project runs on UART communication protocol. Its default baud rate is 9600bps and we are working on the same baud rate to extract GPS data. The GPS module works on NMEA 0183 standards which define the electrical and data specification for communication between the GPS module and its controller. We are using the Recommended minimum specific GPS/Transit data (GPRMC) command. It provides us with three important data which are Fix, Latitude, and Longitude, required for localization and navigation of the car. The update rate of these data from the GPS module is configured at 10Hz and 5Hz for fix control status.

* GPS Configurations:

GPS configuration Settings that we have used for the Adafruit GPS module is shown in the following picture. As per Arduino data-sheet, we can use different commands setting to set the different update rate from once a second (1 Hz) to 10 times a second (10 Hz) as per user requirements.

[[ File: CMPE243_TechSavy_GPS_Config.JPG|600px|thumb|center|| GPS Configuration Settings]]

'''Compass'''

* '''Compass PinOut'''
* VCC: 3.3V Power
* GND: Ground
* SCL: Serial Clock pin connected to SCL of SJOne board
* SDA: Serial DATA pin connected to SDA of SJOne board

A Compass is an instrument used for navigation and orientation that shows direction relative to the geographic cardinal directions (or points). Compass is communicating over I2C with SJ One board. The register 2 and 3 of the compass provide the compass bearing angle (0- 360 range). Calibrating the compass is an important part. We are calibrating it on ‘horizontal calibration mode’, it works for us because the compass has tilt calibration.

We are using the compass in I2C mode of operation. The following table on the left shows the registers and their functions and the software flow chart for getting/setting compass data and calibration on demand and We are using the Compass bearing (16-bit) given by the compass registers 2 and 3 to calculate our car heading.
 

{|
|[[File:CmpE243_I2c_compass_registers.png|thumb|500px|left|thumb|Registers of CMPS11]]
|[[File:CMPE_243_TechSavy_Compass_Calibration.jpg|thumb|450px|Right|thumb|Registers of CMPS11]]
|}
 

===Software Design & Implementation===

The Geographical Controller is in place for navigation purpose. It has two essential parts, namely GPS and compass. It provides direction to the car, by calculating the heading angle and the distance between the coordinates, based on GPS and compass readings. To calculate the heading angle, we need a compass bearing angle and angle between the line joining the two coordinates and the true north(bearing angle for GPS).

 

[[ File: Power_On_SMFC.JPG|600px|thumb|center||Hard Power ON Flow Chart]]

 

[[ File: Periodic_task_SMFC.JPG|500px|thumb|right|| SFMC for 1HZ]]
[[ File: Periodic_task_10Hz_SMFC.JPG|600px|thumb|centre|| SFMC for 10Hz]]

 

==== Distance between the two coordinates calculation ====

The distance between the two coordinates can be calculated using the Haversine formula.

a = sin²(Δφ/2) + cos φ1 ⋅ cos φ2 ⋅ sin²(Δλ/2)
c = 2 ⋅ atan2(√a, √(1−a))
d = R ⋅ c
where,
φ1 = Latitude of 1st Coordinate
φ2 = Latitude of 2nd Coordinate
λ1 = Longitude of 1st Coordinate
λ2 = Longitude of 2nd Coordinate
Δφ = φ2 - φ1
Δλ = λ2 - λ1
d = distance between the two coordinates
R = earth’s radius (mean radius = 6,371km)
Note: All the angles should be in radians.

==== GPS Heading angle calculation ====

[[File:Bearing Angle.JPG|500px|thumb|center|Bearing angle calculation ]]

With reference to the figure, the Heading angle for GPS is the angle between the line joining the two coordinates and the true north. To calculate it graphically, draw a vector pointing towards the destination coordinates from the start point coordinate and measure the angle between the vector and the true north. Use the below formula to calculate the angle mathematically.

Heading angle(α) = atan2(sin Δλ ⋅ cos φ2 , cos φ1 ⋅ sin φ2 − sin φ1 ⋅ cos φ2 ⋅ cos Δλ)
where,
φ1 = Latitude of 1st Coordinate
φ2 = Latitude of 2nd Coordinate
λ1 = Longitude of 1st Coordinate
λ2 = Longitude of 2nd Coordinate
Δλ = λ2 - λ1

==== GPS Checkpoint Navigation ====
The car reads the value of current coordinates from the GPS module to determine its Euclidean distance from the first checkpoint. It also checks the value on the compass to know which direction it should preferably move in i.e. Heading angle. The sensor readings help it ascertain that there isn't an obstacle to hinder its movement in the determined direction.

We have selected 23 checkpoints on the location where the demo is going to takes place and we have filled these coordinates in a Checkpoint Array as shown below.

{|
|[[File:Checkpoints.JPG|thumb|400px|left|thumb|Selected Checkpoints]]
|[[File:CheckPointsArray.JPG|thumb|350px|Right|thumb|Checkpoints Array]]
|}

 

* The Car begins navigating its way from its current location to the final destination using enlisted checkpoints. When the car arrives at a first checkpoint, then GEO Controller will look into its GPS checkpoints constant array to look for next nearest checkpoint.
* While selecting Checkpoint we are using Linear Searching technique to select next checkpoint which is closer to the current location and as well as closer to the final destination.

The Software state machine flow chart for GPS Navigation is shown below:
[[File:Cmpe243_TechSavy_GPS_Navigation.JPG|600px|thumb|centre|GPS Checkpoint Navigation]]

==== Technical Challenges ====

* '''Issues 1''' - GPS doesn’t retain configuration settings; GPS module was forgetting its baud setting of 57600bps configuration settings after a long run testing of GPS module(we kept GPS for overnight testing to capture logs of GPRMC to check its location consistency) before the implementation of Distance calculation so after 4-5 hours its start giving Null values for latitude and longitude after reviewing the logs of the data captured that was giving garbage data as UART baud mismatching gives then it has to be configured again that means baud rate setting using PMTK command.

'''Solution''' - As per recommendation is given in Arduino Data sheet we should use default baud settings of 9600 later we never faced this issue and it was giving a good fix.

*'''Issue 2''' - One of the most important thing with GPS is to get a quick fix. Our First Time to fix was coming approx 50seconds even in the open sky which is not good for self-driving car the moment engine of the car turns on we should have Coordinates of the car to navigate this to the destination location. So first Time to fix was one the hurdle for us.

'''Solution''' - We have followed one of the Arduino Forum in which one of the experts give few tips on how to improve this GPS Fix issue and one of the tips worked for us was the of the Cell battery with the voltage of more than 2.89v. This resolves GPS fix the issue for us.

*'''Issue 3''' - Compass frequently losing its calibration when we were using CMPS11 in calibrated Mode.
'''Solution''' - Using CMPS11 in default calibration mode helped us to get rid of this problem

*'''Issue 4''' Ahhhh!! Faced task overrun issue with GPS NMEA data. When we were using NMEA parsing and shortest path algorithm in one task or even in two different tasks code was crashing like anything. However, NMEA parsing and Path Finding algorithm were working fine.
'''Solution''' - Preet's easy parsing function(using sscanf) and his advice of using separate task using FreeRTOS helped us resolving this problem.

*'''Issue 5''' During parsing of GPS Coordinates we have faced one issue with data type Float. Due to can transmission, we were using float data type for Latitude and longitude and what we have noticed that after getting data in string/char* and converting it to float then last two-three decimal places of latitude and longitude were changing frequently due to which Calculated distance from SOurce to destination was changing randomly even car is sitting at one location.

'''Solution''' - GPS coordinates require double datatype so, we took coordinates as double and then while sending data on CAN we were typecasting that to float. As we were doing all calculation related to coordinates, distance and checkpoints calculations on GEO Controller itself. So after doing all the calculations in double, we were type casting data to float and we were sending that to MASTER & BRIDGE.

 

=='''Bridge Controller Communication'''==
Bridge Controller is used for communication between the SJOne board and the android phone using the HC-05 Bluetooth module. The main purpose of the bridge Controller is to receive the start/stop command and destination location from the Android app. Bridge controller will transmit all the sensor information and debug information and this information will be displayed on the android app.

* BRIDGE CONTROLLER Git Link: [https://gitlab.com/tech-savycmpe243/cmpe243_techsavy_rc_car/tree/master/Bridge_Controller_Module]

===Hardware Design===
'''Bluetooth Module Hardware Interfacing:'''

We are using an HC-05 Bluetooth module to send and receive the data from our android application to Controller. The Bridge controller is connected to the Bluetooth module through the Serial interface(UART2) of SjOne board and we have configured HC-05 at 38400 baud rate 8-bit data and 1 stop bit using modules Communication Mode. Bridge Controller is connected to other SJOne Boards using CAN bus. The Bluetooth module communicates with the SJOne board using UART communication at 38400 baud rate.

[[ File: CmpE243_TechSavy_bridge_HC-05_pin_conf.png|679px|thumb|centre||HC-05 Module Hardware Interfacing]]
 

===HC-05 Bluetooth module===
HC-05 Bluetooth Module is used to set up wireless communication between the Car and the Android phone.
This module is based on the Cambridge Silicon Radio BC417 2.4 GHz BlueTooth Radio chip. This is a complex chip which uses an external 8 Mbit flash memory
It includes the Radio and Memory chips, 26 MHz crystal, antenna, and RF matching network.
The right section of the Bluetooth Board has connection pins for power and signals as well as a 5V to 3.3V Regulator, LED, and level shifting.

* '''HC-05 PinOut'''
* EN: In a case brought HIGH before power is applied, forces AT Command Setup Mode
* VCC: 5V Power
* GND: Ground
* TXD: Serial Transmit pin connected to RXD2 of SJOne board
* RXD: Serial Receive pin connected to TXD2 of SJOne board
* STATE: States if connected or not

* '''LED Blinking signals'''
* Flashing RED Fast: Ready for Pairing with nearby Bluetooth device available
* Flashing RED Slow: Paired and Connected
=== Software Design ===
[[File:tasktableBle.png]]
[[File:Flowchart-reception-1.jpeg]]
[[File:BleTransmission.png]]

=== Technical Challenges ===

* Android App was crashing due to the parsing function when there was no GPS data coming from the Bluetooth module. To solve this problem we added checks in the bridge controller to not to send GPS data if the GPS is not yet fixed.
* Bridge controller's task was getting overrun when used snprint and printf in a task. (printf was just used for initial testing).Then after debugging, we found this problem and removed printf. snprintf and sprintf are working fine in 100Hz function.

 

=='''Master Module'''==
=== Hardware Design ===
====Design and Implementation====
*As name suffice, Master Node acts as the brain of the RC car and gives controlled signals to every other module. 
*It manages the communication among all the modules, including Motor, Sensor, Geographical and Bridge Controller. 
*Master receives periodically data from CAN bus based on message ID of the sender module. 
*Below shows the connection of Master module on the CAN bus, connected with CAN Transceiver.
[[ File: techsavy_master_can.png|679px|thumb|centre||Master-CAN Interfcaing]]

=== Software Design ===
*As the Master takes all the decisions, it has the highest priority and hence the lowest message Id on CAN DBC.
*Figure illustrates the high-level bus flow from master to every module.
[[ File: cmpe243_techsavy_master.gif|679px|thumb|centre||Master Control Flow]]
====Implementation====
'''Heartbeat Message of All Modules'''
*As Master node handles all the communication from other modules, each node continuously sends its heartbeat to master, confirming that it is active and working properly.
* If all the heartbeats are not received by the master, it sends STOP command to bridge so CAR doesn't run into a stage when any one of a node is not working. This mechanism provides us to eliminate running into an error state.
* If the heartbeat is not received, Master handles this using MIA.
*Code below displays heartbeat synchronization and MIA handling of all nodes.

bool hbt_sync_from_all_node(void)
{
is_hbt_sync_flag = sensor_hbt_sync & motor_hbt_sync & gps_hbt_sync & bridge_hbt_sync;
return is_hbt_sync_flag;
}

void master_mia_handler(void)
{
if (dbc_handle_mia_SENSOR_HEARTBEAT(&sensor_hbt, 25))
{
sensor_hbt_sync = false;
}
if (dbc_handle_mia_MOTOR_HEARTBEAT(&motor_hbt, 25))
{
motor_hbt_sync = false;
}
if (dbc_handle_mia_GPS_HEARTBEAT(&gps_hbt, 25))
{
gps_hbt_sync = false;
}
if (dbc_handle_mia_BRIDGE_HEARTBEAT(&bridge_hbt, 25))
{
bridge_hbt_sync = false;
}
}

[[File:master_led.jpg|400x300px|thumb|center|Heartbeat LED of all nodes on Master]]

=== Testing and Technical Challenges ===
* Delay in sending steer command to the motor.
** Initially there was some delay observed while receiving the sensor obstacle information and sending relevant command to motor, because of this synchronization problem we were suffering from the delayed response.
** After plenty of hardware and software debugging, we noticed the buffer size of CAN RX/TX was much larger than required. It was corrected on sensor and motor side as well.
* Taking time in reversing even though the reverse command was send
** Motor took time to reverse as it has to break it's PID loop.
** The solution to this was to send a stop command(0), before sending the reverse command.
<Bullet or Headings of a module>
==== Improper Unit Testing ====
* The problem of CAN buffer described above was detected by Unit Testing itself.
** Along with that bug, I found few more bugs from unit testing the code.

 

=='''Mobile Application'''==
=== Software Design ===

====1. Enable Bluetooth and Connect to bridge controller====

Wireless communication with the car takes places with communication over Bluetooth protocol. Android Application is created which provides an interface to exchange data and configure the car parameters.

The android app connects to the HC-05 BLE module of the bridge controller. The Bluetooth ask the user for permission to access location and prompts to enable Bluetooth if it's already OFF. Our app is designed to connect to only TechSavy Bluetooth module and no other Bluetooth device to ease the setup of Bluetooth communication. A Bluetooth adapter connects to the HC-05 module and opens a Bluetooth Socket over which read and write messages are sent. A thread runs in the background which checks for available data, reads it and the data can then be processed. Data is written via the same Bluetooth socket. Refer to the following link to get started with Bluetooth on Android app and connection to HC-05 module ([http://mcuhq.com/27/simple-android-bluetooth-application-with-arduino-example]).

====2. Start/Stop Command and Log Sensor values====

Start and Stop commands are sent to the RC car via the application. When Start/Stop button is pressed 1 or 0 commands are sent to the bridge controller when then transmits it to the CAN Bus for processing. Bluetooth status, Sensor Values, Motor parameters, GPS location, compass heading angle, distance to the checkpoint is displayed for debugging purpose. Sensor, GPS, motor Messages coming from CAN bus are decoded by the bridge controller and sent to the Android application as a string. The android app parses the string and categorizes the data to store it in appropriate variables. The data is then displayed as a text view in Bluetooth activity. To visit the Map Activity for setting destination and checkpoints a button is added. The map Activity opens on pressing the button.

{|
|[[File:Bluetooth_app.jpg|230px|thumb|The user is asked to enable Bluetooth]]
|[[File:location1.jpg|230px|thumb|User should allow to enable Location]]
|[[File:app_log2.jpeg|250px|thumb|Connecting to the Tech Savy CAR]]
|[[File:app_log.jpeg|250px|thumb|Connected to the module]]
|}

====3. Map Activity====

The map activity is used in our app to show the current location of the car and set the destination marker which the car will navigate too. When map loads in the app the cars current location is indicated coming from the GPS as the source location (Red Marker). The desired location on the map can be set as the destination by long clicking on the map (Light Green marker). The destination can be changed as desired by long pressing again. When the start button is pressed command 1 is sent to the CAN bus via Bluetooth to start the car. A thread starts in the background to indicate the current position of the car when the car moves (light blue marker). Also, a polyline is drawn between the source and destination marker to indicate the direction in which the car will move. For adding Google map to app refer the following [https://www.udemy.com/the-complete-android-oreo-developer-course/](Refer to Maps and geolocation section)

[[File:Map1.jpeg|300px]] [[File:Car_stop.jpeg|275px]]

=== Testing and Technical Challenges ===

1. We faced the problem of adding Bluetooth functionality in the app. There is a lack of tutorials online which shows how to develop an android app with Bluetooth capability and communicating with the HC-05 module. Fortunately, we found this webpage [http://mcuhq.com/27/simple-android-bluetooth-application-with-arduino-example] which helped us and Youtube videos of Coding with Mitch.

2. It was difficult to design the UI on the app with little java and Android experience. We designing UI from mainly two resources [https://www.udemy.com/the-complete-android-oreo-developer-course/] [http://www.deitel.com/Books/Android/Android6forProgrammersAnAppDrivenApproach/tabid/3671/Default.aspx]and searching online for problems faced by us.

3. Initially, we developed the app such that we had to manually connect to a paired device to use Bluetooth functionality. This gave us problems while sending commands to the bridge controller. We solved this problem by fixing the device connection only to our HC-05 module and adding only a single Bluetooth connection button on the app bar for Bluetooth connection.

4. When we received too many sensor values and debug messages from the bridge controller continuously, the app was crashing due to the input buffer overflow. We solved this problem by adding a 1000ms sleep time to limit the input data coming to the app.

5. There was a requirement to continuously update a marker on the map indicating the current location of the car for user feedback. We achieved this using a thread in the background which updated cars position every 1 second.

 

=='''Suggestions for Future Students'''==

* '''For Master Controller'''
** Don't make your obstacle avoidance complex by implementing reverse condition. Just keep your code simple.
** One good approach a developer should follow is to unit test their own code. Would you buy a product which is suppose to be tested later?
** Remember the KISS approach when you code. (Keep It Simple and Stupid).
** For this controller, one should know the basics in C/ C++ and some good debugging skills. Because if you don't have one, you will eventually end up spending more time debugging your problem.
* '''For Hardware Team'''
** Order Hardware and Components as early as possible.
** Select components wisely don't try to save money on this part of the project as bad quality hardware can't help you even with best software implementation.
** Try to power up all modules using 6V coming from LiPo battery. Use IC boosters for converting 6V to 5V and 3.3V. This way there won't be a need of separate power bank and overall weight will be reduced.
** While designing PCB keep the tracing width of power lines to 1 mm so that sufficient current can be pass through it.
** PCB spacing should be 12-15 mil.
** To reduce the magnetic interference from DC Motor, place the compass on the center or near the front side of the car at a height using standoffs.
** Another alternative to standoffs could be implementing ground rings for compass and GPS Antenna which allows passing the EMI directly to the ground.
** Get more samples of CAN transceiver IC's as it can get damaged easily.
* '''For SENSOR Controller Team'''
** LIDAR - It has some limitations when tests/demo takes place in bright sunlight. when direct light falls on it, so gives faulty readings.
** LIDAR Consumes more power, hence need a separate power source for it due to which battery consumption of overall CAR is double as compared to the CAR use ultrasonic sensors for obstacle detection.
** LIDAR is not even cost effective hence should use Ultrasonic instead we realized it very late.
** Sensor Implementation doesn't need any averaging or complex algorithms.
* '''For GEO Controller Team'''
** Suggestions for GEO Controller software development is used FreeRTOS separate Tasks instead of using periodic tasks for NMEA receiving and parsing.
** For GPS Checkpoint navigation use simple and stupid coding no need to implement Dijkstra and complex algorithms for short distance calculation on Geo Controller linear or binary searching technique is enough to implement it successfully.
** For Compass use default calibration mode no need to add any checks and calibrations. Factory mode should be enough to get accurate results.
* '''For Motor Controller Team'''
** Use global pointers while using PWM drivers of SJONE board and set the frequency appropriately before testing it on motor(50Hz or 100Hz is fine).
** Calibrate the ESC first for any RC car you purchase and get that right or the DC motor wont work.
** Clear the CAN buffer periodically or the car might react to the commands with some delay.
* '''Tips for getting GOOD Grades and to remain in top 3 teams'''
** Select your team mates wisely, and make sure every one dedicates them self for this project.
** Be an active member of your team and review rubrics every week before going to demonstrate your CAR.
** As soon as the professor mentioned about the project please start working on the project right from the beginning otherwise at the end you have struggled with finals and you will be left with less time for testing and you have to struggle in demo.
** Although you can get lots of information from seniors still don't take this project light this is a really interesting and challenging project.

=='''Conclusion'''==

[[File:Compass_UnitTesting.JPG|300px|thumb|right|Unit Testing Report Example]]

It was a really great working experience for all of us. We were really thrilled from the beginning that we will be working on something that is quite relevant in the industries these days. We worked as a team of eight which helped us all to know the importance of team-work and co-ordination. We learned many great stuff like

* CAN bus:
** Using this bus, we were able to communicate with five devices connected which each other.
** Also, we learnt how to debug and interpret CAN message using BusMaster.
* LIDAR and ultrasonic sensor:
** At start we felt LIDAR would be easy to use because it gives us the obstacle data for all 360 degree. But as we started using it, we found out that keeping wider angle does not give us accurate data. Then we realised that at after certain distance the angles intersect with each other because of angle spread and we get the same reading for both angle zone. So we selected our angle zone precisely and accurately by doing some trials and error.
* PCB designing:
** We realised that using GPP for long term is not a good idea because every time our car crashed, there were some breakdown in the wires and our CAN bus stopped working. Initially we spent a lot of time debugging hardware and doing soldering.
** So the hardware team started designing the PCB, and when our PCB was mounted on car, we spent hardly any time debugging the hardware.
* We learnt about NMEA data packets while working with GPS and came to know how google map Application actaully works with the help of GPS satellites in view for navigation.
* Unit testing : Unity and cmock framework are great tools for learning and it helped us to get great results in less amount of time. Unit testing of code is a must and should be adopted.
* Git : We learnt all the basic of GIT and it plays an important to role for source code versioning.
There were a lot of problems while doing this project but it was a steep learning curve.
In the end we were able to achieve our objective with really good results.

=== Project Video ===
[https://youtu.be/tvjshIk-hdA Tech Savy Project Video]

=== Project Source Code ===
* Git Project Link: [https://gitlab.com/tech-savycmpe243/cmpe243_techsavy_rc_car] 

=='''References'''==

=== Acknowledgement ===
We would like to express our gratitude to Professor Preetpal Kang for generously sharing his time and knowledge with us and guiding us through the completion of this project.
We would also like to thank the Pratap(ISA) for their valuable advice and constructive feedback.

=== References Used ===

====== LIDAR ======
* [http://www.slamtec.com/en/Lidar/A1 RPLidar Documentation]
====== PID Control ======
* [http://ctms.engin.umich.edu/CTMS/index.php?example=Introduction&section=ControlPID PID Controller Design]
* [https://robotics.stackexchange.com/questions/167/what-are-good-strategies-for-tuning-pid-loops Good Strategies for PID Tuning]
====== LCD ======
* [http://www.4dsystems.com.au/downloads/Application-Notes/4D-AN-00017_R_1_01.pdf Connecting LCD to Host]
====== Android GUI ======
* [https://developer.android.com/studio/write/image-asset-studio.html Create App Icons with Image Asset Studio]
* [https://developer.android.com/training/basics/fragments/index.html Building a Dynamic UI with Fragments]
* [https://www.youtube.com/playlist?list=PL6gx4Cwl9DGBsvRxJJOzG4r4k_zLKrnxl Android Tutorial]
====== Google Maps ======
* [https://developer.android.com/training/maps/index.html Adding Maps]
* [https://developers.google.com/maps/documentation/android-api/marker Markers]
* [https://developers.google.com/maps/documentation/directions/?authuser=1 Google Maps Directions API]

====== PCB Design using DipTrace ======
* [https://diptrace.com/books/tutorial.pdf DipTrace Tutorial]
* [https://diptrace.com/forum/viewtopic.php?t=11533 Diptrace Forum FAQ-1]
* [https://diptrace.com/forum/viewtopic.php?t=10853 DipTrace Forum FAQ-2]

==== Datasheets ====

[1] [https://www.maxbotix.com/documents/XL-MaxSonar-EZ_Datasheet.pdf XL-MaxSonar-EZ4 Ultrasonic Sensor]
[2] [http://www.4dsystems.com.au/productpages/uLCD-32PTU/downloads/uLCD-32PTU_datasheet_R_2_2.pdf 4D Systems LCD]
[3] [https://www.sparkfun.com/datasheets/DevTools/Arduino/MCP2551.pdf CAN Transceiver]
[4] [https://cdn-learn.adafruit.com/downloads/pdf/adafruit-ultimate-gps.pdf GPS Module]
[5] [http://www.pishrobot.com/files/products/datasheets/cmps11.pdf Compass Module]

S20: Canster Truck

2020-05-23T06:52:24Z

Proj user22: /* Project Video */

[[File:CMPE243_S20_T2_Canster_Truck_Logo.png|thumb|455px|caption|right|CAN-STER TRUCK LOGO]]

== '''Abstract''' ==
The Canster Truck Project is an autonomous RC car with CAN Bus interfaced controllers. The development of the RC car's subsystem modules (Interfacing of Ultrasonic Sensor, LIDAR, Bluetooth, GPS, Compass and CAN modules) was divided among six team members. The aim of the project is to develop an autonomous RC Car which can navigate from one source location to the selected destination on the app by avoiding obstacles in its path using sensors. Waypoints algorithm is used as the path finding technique.
 

== '''Introduction and Objectives''' ==

'''The project was divided into 7 modules:'''

* '''Bridge and Sensor Controller'''
* '''Motor Controller'''
* '''Geological Controller'''
* '''Driver and LCD Controller'''
* '''Hardware Integration'''
* '''Android Application'''
* '''Testing & Code Review'''

'''RC Car Objectives'''
'''1. Driver and LCD Controller''' - Handles algorithms for obstacle avoidance, route maneuvering, and waypoints
'''2. Geological Controller''' - Recieves coordinates from GPS and Heading from Compass for navigation
'''3. Motor Controller''' - Controls movements of the RC Car
'''4. Bridge and Sensor Controller''' - Detects surrounding objects and interfaces android application to controller via bluetooth
'''Team Objectives'''

[[File:CMPE243_S20_T2_High_Level_System_Diagram.png|thumb|center|800px| High Level System Diagram]]

 

== '''Team Members and Responsibilities''' ==
[[File:CMPE243_S20_T2_Canster Truck_Team.jpg|thumb|center|800px| Group Picture]]

'''Gitlab Project Link''' - [https://gitlab.com/coder137/can-ster_truck '''Canster Truck''']
 

*'''Niket Naidu''' [https://www.linkedin.com/in/niket-naidu-30090a134/ LinkedIn] [https://gitlab.com/coder137 Gitlab]
** '''Geological Controller''' : GPS, Compass, Waypoint Algorithm, Haversine and Bearing Angle logic
** '''Driver and LCD Controller''' : GLCD
** '''Bridge and Sensor Controller''' : Bluetooth
** '''Testing & Code Review'''

*'''Ganesh Ram Pamadi''' [https://www.linkedin.com/in/ganeshram93/ LinkedIn] [https://gitlab.com/ganeshram2493 Gitlab]
** '''Hardware Integration'''
** '''Testing & Code Review'''
** '''Driver Controller'''
** '''Motor Controller'''

*'''Nikhil Pabbisetty''' [https://www.linkedin.com/in/nikhilpabbisetty/ LinkedIn] [https://gitlab.com/nikhilpeoria Gitlab]
** '''Bridge and Sensor Controller'''
** '''Motor Controller'''
** '''Driver and LCD Controller'''
** '''Hardware Integration'''

*'''Akhil Cherukuri''' [https://www.linkedin.com/in/akhilcherukuri/ LinkedIn] [https://gitlab.com/akhilcherukuri Gitlab] [https://github.com/akhilcherukuri Github]
** '''Android Application'''
** '''Bridge and Sensor Controller'''

*'''Ashish Anant Ladage''' [https://www.linkedin.com/in/ashish-anant-ladage-7bb3a214b/ LinkedIn] [https://gitlab.com/ashishladage1 Gitlab]
** '''Driver and LCD Controller'''
** '''Hardware Integration'''
** '''Motor Controller'''

*'''Jesus De Haro De Reza''' [https://www.linkedin.com/in/jesus-de-haro-66342424/ LinkedIn] [https://gitlab.com/deharo27 Gitlab]
** '''Bridge and Sensor Controller'''
** '''Motor Controller'''

 

== '''Administrative Responsibilities''' ==
* '''Team Lead''' - [https://www.linkedin.com/in/niket-naidu-30090a134/ '''Niket Naidu''']
* '''Git Repository Manager''' - [https://www.linkedin.com/in/niket-naidu-30090a134/ '''Niket Naidu''']
* '''Bill Of Materials Manager''' - [https://www.linkedin.com/in/akhilcherukuri '''Akhil Cherukuri''']
* '''Wiki Report Manager''' - [https://www.linkedin.com/in/akhilcherukuri '''Akhil Cherukuri''']

 

== '''Schedule''' ==

{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-

! scope="row"| '''1'''
| style="text-align:center;" |'''02/11/2020'''
| style="text-align:center;" |'''02/17/2020'''
|
*'''Form teams and decide group name'''
*'''Review past projects'''
*'''Slack: Create project group and invite Preet'''
*'''GitLab: Create project groups repository'''
*'''Analysis of component required'''

|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''2'''
| style="text-align:center;" |'''02/18/2020'''
| style="text-align:center;" |'''02/24/2020'''
|
*'''Study CAN Communication'''
*'''Create Bill of Materials'''
*'''Order RC Car'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''3'''
| style="text-align:center;" |'''02/25/2020'''
| style="text-align:center;" |'''03/02/2020'''
|
*'''Setup team finance management using Splitwise application'''
*'''Complete Bill of Materials'''
*'''Order all other required components'''
*'''Wikipedia: Setup project report template'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''4'''
| style="text-align:center;" |'''03/03/2020'''
| style="text-align:center;" |'''03/09/2020'''
|
*'''Read the respective datasheets and manuals for each component'''
*'''Test each component for working conditions'''
|
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''5'''
| style="text-align:center;" |'''03/10/2020'''
| style="text-align:center;" |'''03/16/2020'''
|
*'''Assign team responsibilities and roles'''
*'''Setup team project management environment (ClickUp)'''
*'''Define CAN DBC'''
*'''Research GPS antennas and order'''
*'''Android: Environmental setup of Android Studio and enable version control'''
*'''Hardware : Decide PCB editing software (easyEDA)'''
*'''Hardware : Draft schematic for required PCB design'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''6'''
| style="text-align:center;" |'''03/17/2020'''
| style="text-align:center;" |'''03/23/2020'''
|
*'''Hardware : Create model of PCB''' 
*'''Android: Add a Button for changing bluetooth connection status in the application''' 
*'''Geological: Interface Compass module with SJ-2 board using I2C interface''' 
*'''Geological: Interface GPS module with SJ-2 board using the UART interface''' 
*'''Geological: Parse raw data to get meaningful values for GPS and Compass''' 
*'''Sensor: Interface and check the functionality of ultrasonic sensors to the SJ-2 board''' 
*'''Motor: Interface of Servo & DC motor to the SJ-2 board and check for basic functionality''' 
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''7'''
| style="text-align:center;" |'''03/24/2020'''
| style="text-align:center;" |'''03/30/2020'''
|
*'''Hardware : Finalize components placement on PCB.''' 
*'''Motor: Add PWM functionality and test the code on DC and servo motors''' 
*'''Sensor: Interface and check and study the output readings of Lidar sensor with SJ-2 board over UART''' 
*'''LCD Display: Explore UI designing of LCD''' 
*'''Hardware: Finalize on optimal ultrasonic sensor placements''' 
*'''Android: Initiate Bluetooth communication and show staus via text view''' 
*'''Wikipedia: Establish final wiki schedule'''
*'''Complete CAN communication format for each controller and link DBC file to the Wiki'''
*'''Complete high-level system block diagram'''
*'''Complete unit-level block diagrams'''
*'''Bridge: Interface HC-5 bluetooth module with Sj-2 board using serial communicaton'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''8'''
| style="text-align:center;" |'''03/31/2020'''
| style="text-align:center;" |'''04/06/2020'''
|
*'''Hardware: Analyze PCB model and order PCB Circuit board''' 
*'''Android: Initiate Bluetooth communication and send "Hello World".''' 
*'''Wikipedia: Start adding information/images/diagrams to the relevant sections'''
*'''Motor: Configure ESC for correct speed outcome according to frequency & PWM values''' 
*'''Motor: Finish RPM sensor hardware and software implementation and integration''' 
*'''Sensor: Read output from Lidar and setup structure for outputting for DBC''' 
*'''Geological: Implement waypoints algorithm''' 
*'''Driver: Implement obstacle avoidance algorithm''' 
*'''Bridge: Pass data such as "Hello World" from HC-05 bluetooth module to bluetooth terminal android application'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''9'''
| style="text-align:center;" |'''04/07/2020'''
| style="text-align:center;" |'''04/13/2020'''
|
*'''Hardware: Remove Unused parts from RC Car''' 
*'''Hardware: Mount PCB and 3D Parts''' 
*'''Motor: Decide different cut-off values from sensor to command right /slight right/ straight/ slight left/ left to motor.''' 
*'''Android: Embed Google Maps API for setting the car's destination.''' 
*'''LCD: Work to show RC cars live status information(battery level, current speed, long, lat, bearing, sensor data, etc)''' 
*'''Driver: Test obstacle avoidance algorithm and fine-tune sensor readings''' 
*'''Geological: Test checkpoint algorithm''' 
*'''Bridge: Establish two way communication between android application and bluetooth module''' 
*'''Update Bill of Materials for miscellaneous hardware'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''10'''
| style="text-align:center;" |'''04/14/2020'''
| style="text-align:center;" |'''04/20/2020'''
|
*'''Hardware: Integrate all hardware modules''' 
*'''LCD: Testing & Validation of the LCD UI and display vehicle status information''' 
*'''Android: Send car location to the app and checkpoints received to Geo module''' 
*'''Motor: Optimize PID control by accelerating/decelerating as instructed by Driver''' 
*'''Bridge: Configure HC-05 for auto reconnection if bluetooth communication disconnects''' 
*'''Add multiple debug messages and transmit on CAN'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''11'''
| style="text-align:center;" |'''04/21/2020'''
| style="text-align:center;" |'''04/27/2020'''
|
*'''Android: Send additional vehicle status information from RC car to the Application for display''' 
*'''Android: Finalize User Interface Design and Icon''' 
*'''Continuously test the whole system and handling of corner cases (outside).'''
*'''Finalize RC Car For Project Proto 1'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''12'''
| style="text-align:center;" |'''04/28/2020'''
| style="text-align:center;" |'''05/04/2020'''
|
*'''Gitlab: Push final code'''
*April 28th: Project Proto 1
*'''Finalize RC Car for Project Demo'''
*May 1st: Project Presentation
*'''Finalize RC Car for Project Proto 2'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''13'''
| style="text-align:center;" |'''05/05/2020'''
| style="text-align:center;" |'''05/21/2020'''
|
* '''Complete Individual Contribution Peer Grading'''
* '''Review and Complete Wiki Project Page'''
|
*'''Completed'''
*'''Completed'''
|-
|}

 

== '''Bill Of Materials''' ==
{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Item#
! scope="col"| Part Description
! scope="col"| Part Model & Vendor
! scope="col"| Quantity
! scope="col"| Cost in USD
|-
! scope="row"| 1
| '''Microcontroller Boards'''
| SJ2 Boards (Purchased from Preet Kang)
| 4
| $200.00
|-
! scope="row"| 2
| '''CAN Transceivers'''
| [https://www.waveshare.com/sn65hvd230-can-board.htm Waveshare SN65HVD230]
| 12
| $54.48
|-
! scope="row"| 3
| '''RC Car'''
| [https://www.amazon.com/Traxxas-Slash-Course-2-4GHZ-Vehicle/dp/B01DU474B0/ref=sr_1_3?ie=UTF8&qid=1474747759&sr=8-3&keywords=Traxxas+1%2F10+slash+2wd Traxxas 2WD RTR with 2.4Ghz Radio]
| 1
| $260.00
|-
! scope="row"| 4
| '''Lithium-Ion Battery'''
| [https://www.rcsuperstore.com/traxxas-7600mah-2s-7-4v-25c-id-lipo-battery-pack/ Traxxas 7600mAh 2S 7.4V 25C iD LiPo Battery Pack]
| 1
| $75.00
|-
! scope="row"| 5
| '''Lithium-Ion Battery Charger'''
| [https://www.amazon.com/Traxxas-2970-EZ-Peak-Charger-Identification/dp/B00OAFYLJC/ref=pd_bxgy_21_img_2?ie=UTF8&psc=1&refRID=JVX791WVV9Y8T9DW92KW Traxxas 2970 EZ-Peak Plus 4-Amp NiMH/LiPo Fast Charger]
| 1
| $50.00
|-
! scope="row"| 6
| '''Compass Breakout Board'''
| [https://www.dfrobot.com/product-1275.html DFRobot CMPS11 Compass]
| 1
| $29.99
|-
! scope="row"| 7
| '''Bluetooth Breakout Board'''
| [https://www.amazon.com/HC-05-Bluetooth-Pass-through-Wireless-Communication/dp/B01G9KSAF6/ref=sr_1_4?ie=UTF8&qid=1507077325&sr=8-4&keywords=arduino+bluetooth+hc-05 DSD TECH Bluetooth HC-05]
| 1
| $8.49
|-
! scope="row"| 8
| '''LIDAR Sensor'''
| [https://www.amazon.com/RPLiDAR-A1M8-Degree-Laser-Scanner/dp/B07H7X3SFF/ref=sr_1_fkmrnull_1?crid=2FSUI76G4UA8K&keywords=rplidar+a1m8+-+360+degree+laser+scanner+development+kit&qid=1552764172&s=gateway&sprefix=RPlidar%2Caps%2C263&sr=8-1-fkmrnull SEEED STUDIO RPLIDAR A1M8]
| 1
| $109.99
|-
! scope="row"| 9
| '''RPM Sensor'''
| [https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM Traxxas 6520 RPM Sensor]
| 1
| $13.70
|-
! scope="row"| 10
| '''GPS Breakout Board'''
| [https://www.adafruit.com/product/746 Adafruit Ultimate GPS Breakout v3]
| 1
| $44.30
|-
! scope="row"| 11
| '''LCD Display'''
| [https://4dsystems.com.au/ulcd-32ptu 4Dsystems 3.2 TFT-LCD ULCD-32PTU]
| 1
| $79.00
|-
! scope="row"| 12
| '''Ultrasonic Sensors'''
| [https://www.amazon.com/gp/product/B01COSN7O6/ ELEGOO HC-SR04 Ultrasonic Module]
| 5
| $12.00
|-
! scope="row"| 13
| '''GPS Antenna'''
| [https://www.amazon.com/dp/B07RRT615K/ GPS Antenna A1-UX]
| 1
| $10.98
|-
! scope="row"| 14
| '''PCB Fabrication'''
| [https://jlcpcb.com/ JLCPCB]
| 5
| $40.15
|-
! scope="row"| 15
| '''Miscellaneous'''
| [https://www.amazon.com Amazon],[https://www.mouser.com/ Mouser Electronics],[https://www.digikey.com/ Digikey],[https://anchor-electronics.com/ Anchor Electronics]
| ~
| $48.07
|-
! scope="row"|
|
|
| '''Total'''
| '''$1036.15'''
|-

|}

 

== '''Printed Circuit Board''' ==

=== Design And Architecture ===
The complete PCB (for boards and hardware peripherals) was designed using EasyEDA online software. The 4 nodes will be communicating via CAN bus and other peripherals are connected to the PCB via headers.

=== Power Section===
We have 2 power banks supplying our system. And the Servo Motor, RPM sensor and DC rear Motor (via ESC) are powered using LiPo battery (6 volts).
* Power bank #1 - Subset 2

* Power bank #2 - Subset 1, Subset 3, Bluetooth Module

'''NOTE:'''

'''Subset 1:'''
1. LIDAR
2. LCD
3. Compass

'''Subset 2:'''
1. Motor node
2. Driver node
3. BS node

'''Subset 3:'''
1. Geo node
2. Back ultrasonic sensor

=== Fabrication ===
* PCB was sent to fabrication to JLCPCB China which provided PCB with MOQ of 5 and 2 layers of PCB and common grounded the rest of the copper area.
'''DRC elements (in mils)'''
* Track Width = 12
* Clearance = 10
* Via Diameter = 24
* Via Drill Diameter = 12

=== Challenges ===
* Auto-routing gave lot of challenges (only ~60% success) and sometimes the online server even crashes and faces downtime. Even local routing had lot of issues. So make sure to plan your design accordingly.
* We started our PCB design well ahead of the project. So lot of pre-planning had to be done with regard to final hardware and placement of components in order to avoid spending extra time and money while re-ordering.
* The PCB went through a lot of internal revisions even before placing order. This was time-consuming.

'''Other hardware challenges:'''
* Figuring out why various hardware peripherals (GPS, Bluetooth, LIDAR and Ultrasonic sensor) started to malfunction (devices were on but values were either inconsistent / not occurring), took a lot of time to debug. It was due to insufficient power.

 
[[File:CMPE243 S20 T2 EasyEDA.png|1040x1200px|thumb|center|PCB Layout Design in EasyEDA]]
 
[[File:CMPE243 S20 T2 PCB SCHEMATIC.jpg|1041x550px|thumb|center|PCB Schematic]]
 
[[File:CMPE243 S20 T2 PCBFRONT.jpg|thumb|center|600px|PCB Top Layer]]
 
[[File:CMPE243 S20 T2 PCBBACK.jpg|thumb|center|600px|PCB Bottom Layer]]

 

== '''CAN Communication''' ==

=== Hardware Design ===
[[File:CMPE243_S20_T2_Canster_Truck_CANHW.png|thumb|center|770px| CAN Hardware Diagram]]

=== DBC File ===

DBC FILE: [https://gitlab.com/coder137/can-ster_truck/-/blob/dbc-improvements/projects/lpc40xx_freertos/project.dbc Gitlab]

<pre>
VERSION ""

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

BS_:

BU_: DBG DRIVER IO MOTOR SENSOR GEO

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" GEO,MOTOR,SENSOR

BO_ 101 GEO_HEARTBEAT: 1 GEO
SG_ GEO_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,MOTOR,SENSOR

BO_ 102 MOTOR_HEARTBEAT: 1 MOTOR
SG_ MOTOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,SENSOR

BO_ 103 SENSOR_HEARTBEAT: 1 SENSOR
SG_ SENSOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,MOTOR

BO_ 200 MOTOR_STEERING: 1 DRIVER
SG_ MOTOR_STEERING_direction: 0|8@1- (1,0) [-2|2] "" MOTOR

BO_ 210 DRIVER_COORDINATES: 8 DRIVER
SG_ DRIVER_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
SG_ DRIVER_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 220 MOTOR_SPEED: 1 DRIVER
SG_ MOTOR_SPEED_processed: 0|8@1- (1,0) [-3|3] "" MOTOR

BO_ 300 GEO_DEGREE: 8 GEO
SG_ GEO_DEGREE_current: 0|32@1+ (0.000001,0) [0|360] "degrees" DRIVER
SG_ GEO_DEGREE_required: 32|32@1+ (0.000001,0) [0|360] "degrees" DRIVER

BO_ 310 GEO_DESTINATION_REACHED: 1 GEO
SG_ GEO_DESTINATION_REACHED_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 400 MOTOR_SPEED_FEEDBACK: 4 MOTOR
SG_ MOTOR_SPEED_current: 0|32@1+ (0.1,0) [0|60] "kph" DRIVER

BO_ 500 SENSOR_BT_COORDINATES: 8 SENSOR
SG_ SENSOR_BT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
SG_ SENSOR_BT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 510 SENSOR_SONARS: 8 SENSOR
SG_ SENSOR_SONARS_left: 0|21@1+ (0.001,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right: 21|21@1+ (0.001,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle: 42|21@1+ (0.001,0) [0|0] "cm" DRIVER

BO_ 520 SENSOR_LIDAR: 8 SENSOR
SG_ SENSOR_LIDAR_middle: 0|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_slight_left: 16|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_slight_right: 32|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_back: 48|16@1+ (1,0) [0|0] "cm" DRIVER

BO_ 530 MOTOR_KEY: 1 SENSOR
SG_ MOTOR_KEY_val: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 900 GEO_CURRENT_COORDINATES: 8 GEO
SG_ GEO_CURRENT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" DBG
SG_ GEO_CURRENT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" DBG

BO_ 901 GEO_DISTANCE_FROM_DESTINATION: 4 GEO
SG_ GEO_distance_from_destination: 0|32@1+ (0.001,0) [0|0] "meters" DBG

BO_ 902 MOTOR_INFO_DBG: 4 MOTOR
SG_ MOTOR_INFO_DBG_rps: 0|16@1+ (1,0) [0|0] "" DBG
SG_ MOTOR_INFO_DBG_pwm: 16|16@1+ (0.001,0) [0|0] "" DBG

BO_ 903 LIPO_BATTERY_VOLTAGE_DBG: 4 MOTOR
SG_ LIPO_BATTERY_VOLTAGE_val: 0|32@1+ (0.01,0) [0|0] "volts" DBG

BO_ 904 CURRENT_CHECKPOINT_DBG: 1 GEO
SG_ CURRENT_CHECKPOINT_val: 0|8@1+ (1,0) [0|0] "" DBG

CM_ "--BU (Network Node) Information--";
CM_ BU_ DRIVER "The driver controller of the car";
CM_ BU_ GEO "The geo controller of the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";

CM_ "--BO (Message) Information--";
CM_ BO_ 100 "Driver Sync message used to synchronize the controllers";
CM_ BO_ 101 "Geo Sync message used to synchronize the controllers";
CM_ BO_ 102 "Motor Sync message used to synchronize the controllers";
CM_ BO_ 103 "Sensor Sync message used to synchronize the controllers";

CM_ BO_ 200 "Steering direction values sent by Driver Node to Motor Node";
CM_ BO_ 210 "Driver Destination coordinates sent by Driver Node";
CM_ BO_ 220 "Required motor speed computed from Driver Node to Motor Node";

CM_ BO_ 300 "Current and computer/required degree values sent by Geo Node";
CM_ BO_ 310 "Indicator signal to check if the RC car has reached the destination";

CM_ BO_ 400 "Current motor info (rps and kph) sent as feedback to the Driver Node";

CM_ BO_ 500 "Coordinate BT values (destination coordinates) sent by Sensor Node";
CM_ BO_ 510 "LIDAR - Distance from obstacle detected in each sector";
CM_ BO_ 520 "Ultrasonic Sensor - Distance from obstacle detected by each sensor";
CM_ BO_ 530 "Start/Stop signal from the Bluetooth app";

CM_ BO_ 900 "Destination coordinates for BUSMASTER debugging";
CM_ BO_ 901 "Distance from destination";
CM_ BO_ 902 "Supplied PWM value to the motor and its RPM";
CM_ BO_ 903 "LIPO Battery Voltage";
CM_ BO_ 904 "Current checkpoint of the car";

CM_ "--SG (Signal) Information for Heartbeats--";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver node";
CM_ SG_ 101 GEO_HEARTBEAT_cmd "Heartbeat command from the geological node";
CM_ SG_ 102 MOTOR_HEARTBEAT_cmd "Heartbeat command from the motor node";
CM_ SG_ 103 SENSOR_HEARTBEAT_cmd "Heartbeat command from the sensor node";

CM_ "--SG (Signal) Information for DRIVER Node--";
CM_ SG_ 200 DRIVER_STEERING_direction "Calculated Driver Steering values (-2,2) for Motor";
CM_ SG_ 210 DRIVER_COORDINATES_latitude "Destination Latitude coordinate";
CM_ SG_ 210 DRIVER_COORDINATES_longitude "Destination Longitude coordinate";
CM_ SG_ 220 MOTOR_SPEED "Calculated Driver speed values (-3,3) for Motor";

CM_ "--SG (Signal) Information for GEO Node--";
CM_ SG_ 300 GEO_DEGREE_current "Current Geo Degree relative to true north";
CM_ SG_ 300 GEO_DEGREE_required "Calculated Geo Degree computed by Haversine Formula";
CM_ SG_ 310 GEO_DESTINATION_REACHED "Indicator signal to check if the RC car has reached the destination";

CM_ "--SG (Signal) Information for MOTOR Node--";
CM_ SG_ 400 MOTOR_SPEED_FEEDBACK "Feedback speed (kph) sent by Motor Node";

CM_ "--SG (Signal) Information for SENSOR Node--";
CM_ SG_ 500 SENSOR_BT_COORDINATES_latitude "Destination Latitude received over Bluetooth";
CM_ SG_ 500 SENSOR_BT_COORDINATES_longitude "Destination Longitude received over Bluetooth";
CM_ SG_ 510 SENSOR_SONARS_left "Ultrasonic Sensor attached to the left side";
CM_ SG_ 510 SENSOR_SONARS_right "Ultrasonic Sensor attached to the right side";
CM_ SG_ 510 SENSOR_SONARS_middle "Ultrasonic Sensor attached to the middle";
CM_ SG_ 510 SENSOR_SONARS_back_left "Ultrasonic Sensor attached to the back left side";
CM_ SG_ 510 SENSOR_SONARS_back_right "Ultrasonic Sensor attached to the back right side";
CM_ SG_ 520 SENSOR_LIDAR_middle "Lidar sensing the middle sector (-15 to 15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_left "Lidar sensing the slight left sector (-45 to -15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_right "Lidar sensing the slight right sector (15 to 45 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_back "Lidar sensing the back of the car (165 to 195 degrees)";
CM_ SG_ 530 MOTOR_KEY_val "1 -> Start the motor from the app, 0 -> Stop";

CM_ SG_ 900 GEO_CURRENT_COORDINATES_latitude "Current Latitude";
CM_ SG_ 900 GEO_CURRENT_COORDINATES_longitude "Current Longitude";
CM_ SG_ 901 GEO_distance_from_destination "Distance from destination";
CM_ SG_ 902 MOTOR_INFO_DBG_rps "Current RPS value of the motor";
CM_ SG_ 902 MOTOR_INFO_DBG_pwm "Supplied motor PWM value";
CM_ SG_ 903 LIPO_BATTERY_VOLTAGE_val "LIPO Battery Voltage";
CM_ SG_ 904 CURRENT_CHECKPOINT_val "Current checkpoint of the car";

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

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

BA_ "GenMsgCycleTime" BO_ 100 1000;
BA_ "GenMsgCycleTime" BO_ 200 50;
BA_ "FieldType" SG_ 100 DRIVER_HEARTBEAT_cmd "DRIVER_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 102 GEO_HEARTBEAT_cmd "GEO_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 103 MOTOR_HEARTBEAT_cmd "MOTOR_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 104 SENSOR_HEARTBEAT_cmd "SENSOR_HEARTBEAT_cmd";

BA_ "FieldType" SG_ 200 MOTOR_STEERING "MOTOR_STEERING";
BA_ "FieldType" SG_ 230 MOTOR_SPEED_val "MOTOR_SPEED_val";
BA_ "FieldType" SG_ 310 GEO_DESTINATION_REACHED_cmd "GEO_DESTINATION_REACHED_cmd";

VAL_ 100 DRIVER_HEARTBEAT_cmd 2 "DRIVER_HEARTBEAT_cmd_REBOOT" 1 "DRIVER_HEARTBEAT_cmd_SYNC" 0 "DRIVER_HEARTBEAT_cmd_NOOP" ;
VAL_ 101 GEO_HEARTBEAT_cmd 2 "GEO_HEARTBEAT_cmd_REBOOT" 1 "GEO_HEARTBEAT_cmd_SYNC" 0 "GEO_HEARTBEAT_cmd_NOOP";
VAL_ 102 MOTOR_HEARTBEAT_cmd 20 "MOTOR_HEARTBEAT_cmd_REBOOT" 10 "MOTOR_HEARTBEAT_cmd_SYNC" 0 "MOTOR_HEARTBEAT_cmd_NOOP" ;
VAL_ 103 SENSOR_HEARTBEAT_cmd 200 "SENSOR_HEARTBEAT_cmd_REBOOT" 100 "SENSOR_HEARTBEAT_cmd_SYNC" 0 "SENSOR_HEARTBEAT_cmd_NOOP" ;

VAL_ 200 MOTOR_STEERING_direction -2 "MOTOR_STEERING_hard_left" -1 "MOTOR_STEERING_slight_left" 0 "MOTOR_STEERING_straight" 1 "MOTOR_STEERING_slight_right" 2 "MOTOR_STEERING_hard_right";
VAL_ 220 MOTOR_SPEED_processed -3 "MOTOR_SPEED_reverse_fast" -2 "MOTOR_SPEED_reverse_medium" -1 "MOTOR_SPEED_reverse_slow" 0 "MOTOR_SPEED_neutral" 1 "MOTOR_SPEED_forward_slow" 2 "MOTOR_SPEED_forward_medium" 3 "MOTOR_SPEED_forward_fast";
VAL_ 310 GEO_DESTINATION_REACHED_cmd 1 "GEO_DESTINATION_REACHED_cmd_REACHED" 0 "GEO_DESTINATION_REACHED_cmd_NOT_REACHED";
</pre>

 

== '''Motor Controller''' ==
'''[https://gitlab.com/coder137/can-ster_truck/-/tree/motor_bleeding_edge_dev GitLab Link]'''

This controller is used to control the components of the car-related to motor. We can control the speed and steering of the car having interfaced with various components with the SJ-2 board. The servo motor is controlled via PWM and is used to set the steering direction of the car. The DC motor is controlled by the Electronic Speed Controller (ESC) via PWM for speed. We read the speed of the car by using an RPM sensor. By using the RPM sensor values, a feedback loop has been designed to regulate the speed of the car. A state machine has been designed to manage the forward and backward movements of the car.
Additionally, a voltage divider circuit has been implemented to read the battery voltage. All motor functionality and CAN message communication is run at 10 Hz.

=== Hardware Design ===

[[File:CMPE243_S20_T2_Canster_Truck_Motor_Hardware.png|thumb|center|750px| Motor Hardware System]]

The following diagram details the hardware implementation of the motor module with the SJTwo board:
Hardware Interface
=====Servo Motor=====
The servo motor responds to PWM pulses. It has three pins namely Vcc, PWM Input Signal, and GND. The servo is powered using 6V from the car battery. Based on the PWM signal supplied from the SJTwo board the front wheels are turned.
[[File:CMPE243_S20_T2_Canster_Truck_Motor_1.jpg|440px|thumb|center|| Servo Motor]]
{| class="wikitable" style="text-align: center; width: 400px; height: 200px; margin: left;"
|+ Servo Motor Pin Connection
|-
! Sr. No.
! Wires - Servo Motor
! Function
|-
! 1
| PWM Connected to P2.5 || PWM Signal from Sj-2 Board
|-
! 2
| VCC || 6V supply from ESC
|-
! 3
| GND || Common Ground
|-
|}

=====Electronic Speed Controller (ESC)=====
The ESC is used to control the DC motor. It is supplied power using the 7.4 V LiPo battery. It has three pins namely Vout, PWM Input Signal, and GND. Based on the PWM input signal, the speed and forward, neutral, and backward movements of the car is changed. Vout is given to the RPM sensor and Servo motor.
[[File:CMPE243_S20_T2_Canster_Truck_Motor_2.jpg|440px|thumb|center|| Electronic Speed Controller (ESC)]]
{| class="wikitable" style="text-align: center; width: 400px; height: 200px; margin: left;"
|+ Speed Sensor Pin Connection
|-
! Sr. No.
! Wires - RPM Sensor
! Function
|-
! 1
| Signal Wire Connected to P2.0 || GPIO that supplies pulses to controller
|-
! 2
| VCC || 6V supply from ESC
|-
! 3
| GND || Common Ground
|-
|}

=====DC Motor=====
The DC motor is controlled using the ESC. It has two pins, a positive and a negative terminal. A PWM signal wire is connected to the microcontroller and the required current is provided by the LiPo battery and the ESC. The DC motor is controlled using PWM at 10Hz.

[[File:CMPE243_S20_T2_Canster_Truck_Motor_3.jpg|320px|thumb|center|| DC Motor]]
{|
|-
|
{| class="wikitable" style="text-align: center; width: 400px; height: 200px; margin-left:0px;"
|+ DC Motor Pin Connection
|-
! Sr. No.
! Wires - DC Motor
! Description
|-
! 1
| Positive Wire (already connected) || Positive Terminal
|-
! 2
| Negative Wire (already connected || Negative Terminal
|-
|}
 
{| class="wikitable" style="text-align: center; width: 400px; height: 200px;"
|+ DC Motor Configuration
|-
! Operation
! Pulse Width Range (ms)
! Duty Cycle(%)
|-
! FORWARD
| 1.51 - 2.00 || 15.1-20.0
|-
! STOP
| 1.50 || 15.0
|-
! REVERSE
| 1.00 - 1.49 || 10.0-14.9
|-
|}
|
|-
|}

Note: First calibrate the DC motor or the motor will not respond to your PWM pulses. For help with calibration go to this [https://traxxas.com/support/Programming-Your-Traxxas-Electronic-Speed-Control website]

=====RPM Sensor=====

The RPM sensor is used to get the current speed of the car. We use the info for creating a feedback loop (PID) for maintaining the speed of the car in uphill and downhill situations. The RPM sensor mounts on the rear DC motor shaft compartment with a special assembly also provided by Traxxas. The magnet which attached to the inner gear generates a pulse each rotation. The sensor works on the hall effect principle where it provides a current across its terminal when placed in a magnet's field. The RPM sensor has three pins namely Vcc, Signal, and GND.

[[File:CMPE243_S20_T2_Canster_Truck_Motor_4.jpg|440px|thumb|center|| RPM Sensor]]

{| class="wikitable" style="text-align: center; width: 400px; height: 200px; margin: left;"
|+ Speed Sensor Pin Connection
|-
! Sr. No.
! Wires - RPM Sensor
! Function
|-
! 1
| Signal Wire Connected to P2.2 || GPIO that supplies pulses to controller
|-
! 2
| VCC || 6V supply from ESC
|-
! 3
| GND || Common Ground
|-
|}

=== Software Design ===

The software for the motor node was divided into multiple files and made modular to improve readability and understanding of the complex logic involved. The main code modules are for:
*Servo Motor
*Electronic Speed Controller
*RPM Sensor
*Motor Wrapper
*Battery Voltage

The motor wrapper module is used to wrap all the code from the esc, servo, and rpm modules into simple to use functions to be called in the periodic tasks.
=====Servo Motor=====
It uses the steering value sent from the driver (-2 to 2) and matches it to the appropriate PWM value for steering. This code module is run at 10Hz.
<pre>
void servo__steer_processor(int16_t steering_value) {
switch (steering_value) {
case MOTOR_STEERING_hard_left:
servo__steer_hard_left();
break;
case MOTOR_STEERING_slight_left:
servo__steer_soft_left();
break;
case MOTOR_STEERING_straight:
servo__steer_straight();
break;
case MOTOR_STEERING_slight_right:
servo__steer_soft_right();
break;
case MOTOR_STEERING_hard_right:
servo__steer_hard_right();
break;
default:
printf("\nDid not receive steering value");
}
}
</pre>
=====Electronic Speed Controller=====

This code module is used to control the DC motor. It receives the motor direction value from the driver and sets the appropriate PWM value. Based on the value the motor is commanded to move the car forward or backwards. A switch case is implemented to set PWM values for movement in different directions along with different speeds.
<pre>
void esc__direction_processor(int16_t direction_value) {
desired_direction_value = direction_value;
switch (direction_value) {
case MOTOR_SPEED_reverse_fast:
esc__reverse_fast();
break;
case MOTOR_SPEED_reverse_medium:
esc__reverse_medium();
break;
case MOTOR_SPEED_reverse_slow:
esc__reverse_slow();
break;
case MOTOR_SPEED_neutral:
esc__neutral();
break;
case MOTOR_SPEED_forward_slow:
esc__forward_slow();
break;
case MOTOR_SPEED_forward_medium:
esc__forward_medium();
break;
case MOTOR_SPEED_forward_fast:
esc__forward_fast();
break;

default:
printf("\nDid not receive direction and speed value");
}
}
</pre>

There is also a feedback loop to control the speed. The ESC code depends on the rpm sensor code for the current speed values.
<pre>
double current_speed = get_speed_kph();
double desired_speed = desired_speed_kph;
float adjusted_duty_cycle = 0.0;
adjusted_duty_cycle = duty_cycle + (speed_to_pwm_adjustment(desired_speed, current_speed));
</pre>

[[File:CMPE243_S20_T2_Canster_Truck_Motor1.png|thumb|center|500px| Feedback Loop for Motor Speed]]

=====RPM Sensor=====
This code module is used to get current speed data from the RPM sensor. It is based on interrupts. When the wheel rotates once, we get one pulse due to the magnet installed. This pulse generates a falling edge interrupt during which we increment the pulse counter. Since, this code is run at 1Hz we collect the number of pulses generated every one second. This gives us the number of rotations per second using which we can calculate the speed in kph.
<pre>
float rpm__calculate_speed_kph() {
uint16_t rotation_per_sec = pulse_count;
pulse_count = 0;
speed_kph = ((CIRCUMFERENCE_METER * rotation_per_sec) * (MPS_TO_KPH_CONVERSION_FACTOR)) / GEAR_RATIO;
return speed_kph;
}
</pre>

=====Motor Wrapper=====
As mentioned above, the main function of this code module is to wrap all the other code modules and call the right functions at the appropriate frequency. The motor wrapper code also includes a state machine for ensuring a smooth transition between forward to backward state and vice versa. In order to achieve a smooth transition, a series of PWM pulses must be generated at the right time. For example, when the motor is moving from forward to backward state, a reverse value must be given first followed by at least three neutral values, and then continue with reverse values.

[[File:CMPE243_S20_T2_Canster_Truck_Motor2.png|thumb|center|500px| State Machine Flowchart for Motor Movements]]

=====LiPo Battery Voltage=====

The LiPo Battery Voltage was calculated using ADC in Burst Mode. A LiPo Hardware module was created for the same which contained two functions, <code>lipo__init</code> and <code>lipo__get_voltage</code>.

The voltage divider circuit is stepped down from 7.4V to 2.1V using 10K and 4K Resistor pair.
[[File:CMPE243_S20_T2_Canster Truck_Motor_Voltage_Regulator.png|thumb|center|400px| Voltage Regulator]]
'''LiPo Initialization'''

The LiPo Initialization phase initializes the ADC, Enables Burst mode on the ADC pins and configures the Alternate Function Registers for the same.

'''Getting LiPo Voltage'''

We read the raw ADC value from the LPC Hardware register. This value will be from 0 - 3.3V. However due to our voltage divider configuration the max voltage that we should theoretically get is 2.1V. This means that 2.1V corresponds to 7.4V of the LIPO Battery voltage.

The formula used is
<code>(raw_adc_value * MAX_LIPO_BATTERY_VOLTAGE_VALUE) / MAX_LIPO_ADC_VALUE</code>

=== Technical Challenges ===
<li>Changing movements of the car from Forward to Backward and vice versa
If you just change the PWM value from say 16 (Forward) to 14(Backward), the DC motor will just stop and will not make wheels turn reverse. We discovered this problem quite late as during the initial testing we had always run the car from the start with either forward or reverse but never tried changing the direction during run-time.
 
Solution: The motor requires a series of PWM pulses which is specific to the car to transition from forward mode to reverse mode. In our case we had to give the PWM pulses in the following sequence. Suppose,
<ol>
<li> Forward (16) (callback_count = 0)</li>
<li> Forward (16) (callback_count = 1)</li>
<li> Reverse (14) (callback_count = 2)</li>
<li> Neutral (15) (callback_count = 3)</li>
<li> Neutral (15) (callback_count = 4)</li>
<li> Neutral (15) (callback_count = 5)</li>
<li> Reverse (14) (callback_count = 6)</li>
<li> Continue reverse</li>
</ol>
Similarly, the reverse to forward can also be implemented.
<li>DC motor shooting off when there is an improper ground connection
When we connected the battery voltage circuit for reading the voltage from the battery, the motor would randomly shoot off every now and then.
 
Solution: Connect the voltage divider circuit to the common ground rather than taking the ground from the ESC.</li>

 

== '''Geological Controller''' ==
'''[https://gitlab.com/coder137/can-ster_truck/-/tree/geo_bleeding_edge_dev_waypoints GitLab Link]'''

===Messages===
*GEO_HEARTBEAT: Used to check for MIA by other nodes. Highest priority message for GEO Node

*GEO_DEGREE: Sends the current degree relative to the North Pole computed by the Compass and the Required degree relative to the North Pole computed by Bearing Angle using the Current Coordinate and Destination Coordinate.

*GEO_DESTINATION_REACHED: Sets a flag, 0 for destination not reached and 1 for destination reached

*GEO_CURRENT_COORDINATES: Debug Message used to send the Current GPS Coordinates

*GEO_DISTANCE_FROM_DESTINATION: Debug message used to send the Distance from Destination

*CURRENT_CHECKPOINT_DBG: Debug message used to check which checkpoint is being navigated to

=== Hardware Design ===

[[File:CMPE243_S20_T2_GEO1.png|thumb|center|650px| Geological Diagram]]

=== Software Design ===
=====Overview=====
*Inside the `periodic_callback__initialize`
**Initialize the CAN BUS
**Initialize the GPS

*Inside the `periodic_callback__1hz`
**Handle all MIA (from other Nodes)
**Update GPS LED when init and in case of failure
**Compute the GEO logic for Waypoints algorithm once every second (1000 ms)

*Inside the `periodic_callback__10hz`
**Handle CAN Incoming messages (Decode)
**Transmit CAN Geo messages (Encode and send)
**Compute the GPS Coordinate

=====Compass I2C Driver=====
An online datasheet resource was used to work with the Compass ([https://www.robot-electronics.co.uk/htm/cmps11i2c.htm CMPS11 Datasheet])
Initially the Compass I2C Driver was tested using the Terminal I2C Helper built by our Professor Preetpal Kang. Using this resource we were quickly able to read various I2C Registers and display it onto the terminal.

For our project the only required part of the Compass was the 16-bit Compass Bearing value (0-3599) i.e 0-359.9 degree values. These values were stored in the 2nd and 3rd register (Register 2 being the High Byte).
Once the raw data was received over I2C we could easily combine the data

<pre>
uint16_t bearing_value = (Reg2 << 8) | Reg3;
float rval = bearing_value / 10.0;
return rval;
</pre>
The returned value were transmitted to the Driver Node to compute its steering based on the required Bearing Angle.

=====GPS Initialization=====
GPS Initialization activates the Hardware GPIO (RX and TX), FreeRTOS Queue for UART Interrupts (UART Module) and Line Buffer Module to parse each GPS line.

=====GPS Data Parsing=====
The GPS Hardware module transmits an NMEA string over UART to the SJTwo Board. We read each character one by one and add it to the Line Buffer module.
Inside its computation loop, the Line Buffer module checks if a newline character has been received.
When a newline character has been received the entire string is extracted from the line buffer module and parsed according to its identifier ($GPRMC, $GPGGA) received and parsed into individual tokens.
For our purposes the $GPRMC NMEA string was the most appropriate and it helped us extract the Current Latitude Longitude as well as the Valid/Invalid tag for the Canster Truck.

=====GPS LED Indication for debugging=====

A simple module that checks for the GPRMC GPS Message and extracts the A or V valid (Tag). If $GPRMC NMEA string is valid, LED is set, else LED is reset. This gives us onsite debugging capabilities to know if GPS has locked onto a satellite signal.

=====GEO Logic Module Computation=====
The GEO Logic Module computes the Bearing Angle, Haversine Distance as well as the Waypoints algorithm.

'''Bearing Angle:'''

<code>
θ = atan2( sin Δλ ⋅ cos φ2 , cos φ1 ⋅ sin φ2 − sin φ1 ⋅ cos φ2 ⋅ cos Δλ )
</code>

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

Since atan2 returns values in the range -π ... +π (that is, -180° ... +180°), to normalize the result to a compass bearing (in the range 0° ... 360°, with −ve values transformed into the range 180° ... 360°), convert to degrees and then use (θ+360) % 360, where % is (floating point) modulo.
For final bearing, simply take the initial bearing from the endpoint to the start point and reverse it (using θ = (θ+180) % 360).

The above article reference gives us the required bearing angle that our car must align itself to, to reach a particular destination coordinate from its current coordinate.
The Steering of the vehicle depends on the above-computed angle values.

'''Haversine Distance Formula:'''

This uses the ‘haversine’ formula to calculate the great-circle distance between two points – that is, the shortest distance over the earth’s surface – giving an ‘as-the-crow-flies’ distance between the points (ignoring any hills they fly over, of course!).

<code>
a = sin²(Δφ/2) + cos φ1 ⋅ cos φ2 ⋅ sin²(Δλ/2)

c = 2 ⋅ atan2( √a, √(1−a) )

d = R ⋅ c
</code>

where φ is latitude, λ is longitude, R is earth’s radius (mean radius = 6,371km);
note that angles need to be in radians to pass to trig functions!

The above formula is used to calculate the distance between the source coordinate (received via GPS) and the destination coordinate.
Later this was used to compute the distance between source coordinate and each individual checkpoint to traverse the shortest distance.

'''Waypoints Algorithm:'''

The Waypoints algorithm that was chosen was a slightly modified version of Djikstra’s Algorithm.
3 values were calculated before the final computation

* Distance between source and final destination (DISTsd)
* Distance between source and each individual checkpoint (DISTsc)
* Distance between each individual checkpoint and the final destination. (DISTcd)

If '''DISTsd''' was lesser than '''DISTcd''', this checkpoint was discarded (we continue in the loop). Since we would be moving in the opposite direction, rather than towards the final destination.

If '''DISTsd''' was greater than '''DISTcd''', then we checked the nearest checkpoint to the source.
The minimum value was set initial that was equal to '''DISTsd'''.

If '''DISTsc''' was lesser than the minimum value stored, '''DISTsc''' would become the new minimum value, and the checkpoint index and coordinates would be appropriately stored and returned from the function.

In this way we would navigate to the nearest checkpoint from the source, while also making sure NOT to travel in the opposite direction.
This logic is recomputed only when we reach the checkpoint selected and the algorithm runs again to find the next checkpoint that we need to navigate to.

=====CAN Decode Destination Coordinates=====
Destination Coordinates are received from the Bridge and Sensor Node and transmitted over the CAN Bus. The value is decoded and stored in the GEO Logic Module.
This is a very important value since our entire GEO Logic calculations are based on the Destination Coordinate.

=====CAN Encode and Send=====

The main messages that were transmitter are
#Geo Degree
#Geo Destination Reached
#Distance from Destination Debug and Checkpoint Index debug

'''Geo Degree Computation as per Waypoints Algorithm:'''

Geo Degree was computed as per the current coordinates and the most recently computed checkpoint coordinates. This bearing angle calculation w.r.t computed checkpoint would continue till we do not reach that particular checkpoint.
Once we reach the computed checkpoint, Waypoint algorithm is recomputed as per the process mentioned above and the algorithm runs again.

'''Geo Destination Reached:'''

An Area of around 4 meters was set around the destination coordinate to check if the destination had been reached.
This measurement was taken into consideration to allow for the loss in precision when transmitting data over CAN as well as any irregularities that might occur when getting values from the GPS.
Having an area of 4 meters was very accurate for all of our test runs.

'''Geo Distance from Destination Debug and Checkpoint Index Debug:'''

Getting debug information was very critical to speed up our development process. In this case we could actively see if our algorithm worked properly.
The Geo Distance from Destination was used to see if we were moving closer to our destination or veering further away from it.
The Checkpoint Index was used to see which checkpoint index we were traveling to. By knowing the placements of the Individual checkpoints we could manually as well as programmatically (via Android application) verify the working of our Canster Truck.

=== Technical Challenges ===
#DBC Challenge for GEO Coordinates -> Could not encode more than 5-6 decimal places at a time, on later investigation we found that the 10000 is an int value, however 100000 overflows the int value.
#Creating an efficient algorithm for Waypoints, O(n) complexity.
#Getting appropriate fixes for GPS when not in a completely open space.
#GPS used to fluctuate or stop giving values when Battery voltage went below a particular threshold. Always supply 3.3V constantly at a good amperage.

 

== '''Sensor [Bridge and Sensor Controller]''' ==
'''[https://gitlab.com/coder137/can-ster_truck/-/tree/sensor_bleeding_edge_dev GitLab]'''
==='''Ultrasonic Sensor'''===
====Hardware Design====
This sensor uses an ultrasonic beam to measure the distances. Based on the time taken between when the beam is sent and received back to the sensor, the distance is calculated in the node.
Apart from 5v and GND, this sensor has 2 pins ECHO and TRIG which are interfaced with the SJ-Two board via GPIO.

[[File:CMPE243_S20_T2_CansterTruck_ultrasonic_sensor.jpg|thumb|center|300px| Ultrasonic Sensor Diagram]]

====Software Design====
* Init the GPIO pin connected to TRIG of the sensor as output and for ECHO as an input port.
* Attach the interrupt on the ECHO input port.
* Store the system_clock_count before setting the trigger pulse and then set the pulse. Also keep monitoring the input port.
* Take the system_clock_count at the instant of receiving the interrupt.
Distance = (system_clock_count_at_trig - system_clock_count_after_at_echo) / 57.14

==='''Lidar Sensor'''===
====Hardware Design====
The RPLidar sensor can be powered from a 5v source and uses UART communication to receive commands and transmit data. It has seven pins to interface with. Two sets of the pins (four total) are for power and ground. The remaining three are for UART receive and transmit, and for making the lidar’s motor spin.

[[File:CMPE243_S20_T2_Canster_Truck_RPLidar_A1.JPG|thumb|center|300px| RPLidar A1]]

====Software Design====
In terms of the lidar, the SJ2 initializes GPIO, UART, and memory for storing the measurement values. After initialization, the command to begin scanning is sent. Here, we wait for the lidar to send a response packet, letting the host (SJ2 board) know it received the command. The response packet the lidar sends will be 7 bytes. If the correct 7 bytes are not received, the command will be sent again.

[[File:CMPE243_S20_T2_Canster Truck_Lidar_flow.jpeg|thumb|center|200px| Lidar Flow]]

Following the response packet, the lidar begins sending 5-byte measurement data. Each sample contains a distance measurement (in millimeters) and the angle (with respect to the lidar) in which it was taken. The data packet structure is shown in the following figure. In addition to containing the distance and angle, the packet includes a quality value, to indicate the reliability of the measurement, and three check bits (S, ~S, and C). As the data is received via UART, we wait until we have 5 bytes before continuing to process. Before processing the 5 bytes after receiving them, the check bits are confirmed to be correct. If they are incorrect, it will not be processed and we will wait for another sample to be received.

[[File:CMPE243_S20_T2_Canster Truck_DataPacketStructure.JPG|thumb|center|200px| Data Packet Structure]]

In the case the sample is correct, each measurement value that is in a direction of interest will be placed in an array designated to one of four directions (left, right, front, rear). Each of these directions have their own sector in the lidar’s 360-degree view.
*Right sector: 11° - 30°
*Rear sector: 170° - 190°
*Left sector: 330° - 349°
*Front sector: 350° - 370° (or 10°)

The arrays mentioned will hold roughly 20 measurements, which are every degree in the sector. In the event, objects are too far to measure, the lidar will report 0 mm. distance. Since there is no measurable obstacle, a “large” distance value of 3000 mm. is placed in the array. The smallest distance value will be taken from each array and reported to the driver node for obstacle avoidance.

=== Technical Challenges ===
====Ultrasonic Sensor====
*'''Power issue''' The pulses were getting triggered incorrectly and it took a while to figure out that it was due to insufficient power.

====LIDAR====
*'''Datasheet not 100% clear:''' The correct datasheet for the was a bit difficult to obtain, and the manufacturer needed to be contacted. The first document found online was high level and general information about the sensor, but the manufacturer did provide another document that contained the information of the commands and responses to and from the lidar, and their packet structure. The documents did not clearly state the angles with respect to the lidar are fixed, which left me wondering if the lidar will think the direction it is facing when powered on will become the new “zeroth” angle.

*'''UART Buffer Overflow:''' When first interfacing with the sensor, the incoming bytes of the lidar were printed on to the terminal to make sure there was a response and to make sense of the information. Since the command we sent results in 5 bytes of data per measurement samples from the lidar and the lidar measured 2000 times per second, there are will be roughly 10k Bytes per second of data incoming that need to be handled continuously. With an improperly sized UART buffer and print statements it is guaranteed to occur, making the lidar data look like random values.

*'''Proper Parsing of Measurement Data:''' After sending a command to the lidar, the sensor will send a response packet, followed by the measurement data. The initial response from the lidar is a 7-byte packet, followed by continuous 5-byte measurement samples. I needed to make sure however I handled the response would be independent of how the measurement is handled, so as not to create a potential unwanted offset when receiving measurements.

*'''Object Detection with Received Data:''' Once proper communication was set up with the lidar and measurement data was getting decoded, there needed to be a way to measure when obstacles were present. If ~360 measurements are handled entirely independently from one another, it could become a complex and confusing code. To achieve a simple approach, four sectors about 20 degrees in size were used to represent the front, left, right, and rear directions.

*'''Bugs in Code:''' When first implementing the code, there were a few bugs from typos, incorrect numbers, and some faulty logic that were found with the use of unit testing. Unit testing helped find these issues and verified the logic was correct, and I would say gave me 90% confidence in my lidar handling.

 

== '''Bluetooth Module [Bridge and Sensor Controller]'''==

Bridge functionality of the Bridge and Sensor Controller is to establish wireless communication between the SJ-2 Board and the android mobile device using the HC-05 Bluetooth module. The Bridge controller will be receiving start command with destination GEO coordinates and stop command. The Bridge controller will be transmitting the required sensor data and debug information to be displayed on the android application.

[[File:CMPE243_S20_T2_BRIDGE.png|thumb|center|500px| Bridge Diagram]]

==== Software Design ====

'''Low-Level Layer'''

In this layer, similar to the GPS the UART GPIO was initialized (RX, TX), FreeRTOS Queue was initialized for UART Interrupts and the line buffer module was initialized to parse strings.

Two basic functions <code>bt__read</code> and <code>bt__write</code> were implemented.
As the name suggested, <code>bt__write</code> took a string as its input parameter and transmitted that data to the Android application. <code>bt__read</code> stored the incoming characters into the line buffer, parsed the line received into its identifier and tokens, and invoked a callback function.

Since this was a low-level layer the User would not be directly invoking this library. Instead a '''Bluetooth Wrapper''' module was created which would be invoked and used by the user.

'''Application Layer'''

The Bluetooth Wrapper module had the appropriate <code>read_once</code> and <code>write_once</code> functions.

The <code>read_once</code> function internally just called the <code>bt__read</code> function. All of the decodings was done inside the Callback Function.
To get the Destination coordinate the string received from the Android Application was in the form of
<code>$loc,<destination_latitude>,<destination_longitude>.</code>
Upon receiving this data we parsed the destination_latitude and destination_longitude, which could later be accessed using getters.
We also set a start flag to notify the Driver Node that destination has been received and we can start steering towards our checkpoints.

Another command implemented was the stop command.
<code>$stop</code>
This was used to send a stop flag to the Driver node.

The <code>write_once</code> function used the getter methods from each CAN Decode message and update its internal state variables. A CSV String was created using the <code>$canster</code> identifier and various debugging points were appended to this message using a comma.
On the Android application side this CSV string was tokenized and displayed onto the Application Debug screen appropriately.

==== Technical Challenges ====

'''Bluetooth peripheral not turning on'''
* We initially connected the Bluetooth module directly to the SJ-Two board with (Vcc = 3.3v). But it was not giving only 2.7v and hence the device did not turn on.
* We had to connect it to external power source to make it function without hassles.

 

== '''Driver [Driver and LCD Controller]''' ==
'''[https://gitlab.com/coder137/can-ster_truck/-/tree/driver_bleeding_edge_dev GitLab]'''

=== Software Design ===

[[File:CMPE243_S20_T2_Canster Truck_Driver_Flowchart.png|thumb|center|750px|Driver Flowchart]]

The above block diagram explains the process flow of obstacle detection for the car. The LIDAR detects
the obstacle and depending on the distance of obstacle the car takes a slight right and slight left or a
hard right and hard left. The state of the car also depends on the value of the LIDAR and ultrasonic sensor.
The loose ends of the LIDAR for the reverse condition are checked by the ultrasonic sensors. The
The ultrasonic sensor works on the principle of trigger and echo and can detect the obstacles very close by.
The range of the Ultrasonic sensor is lower than the LIDAR. Finally, if no obstacle is detected the car goes
straight until the destination is reached. The speed of the car is also various when an obstacle is detected to
avoid the crash and the car’s smooth transition from one state to another. The key to the android
application controls the start and stop the process of the car. If the key is not pressed, then the stays in the

neutral state. The speed of the car is controlled by the changing duty cycle of the input voltage. There
are seven-speed levels in which the motor can run on. These speed levels are Forward Slow, Medium,
Fast, Reverse Slow, Medium, Fast, and Neutral. The Neutral is the stop condition with a 0% duty cycle.

=== Technical Challenges ===

Technical Challenges faced during obstacle detection:

*Due to dimensions of the car and for the perfect obstacle avoidance the values of 100cm and 150cm had to be selected for the turning radius. Hence, it is very important to calibrate these values appropriately, as these values will be unique for different car designs.
*For a situation, where even if the lidar doesn’t detect any obstacle at the middle, the car must take a slight right or a slight left as per our design. This is the case where the obstacle can be a moving one and that is why the lidar middle couldn’t detect it.

 

== '''LCD [Driver and LCD Controller]''' ==
=== Hardware Design ===
[[File:CMPE243_S20_T2_Canster_Truck_LCD_Diagram.png|thumb|600px|center| LCD Design]]
{|style="text-align: center; width: 400px; height: 200px; margin: auto;"
|
[[File:CMPE243_S20_T2_Canster_Truck_GLCD.jpg|thumb|200px|center| GLCD Hardware]]
||
[[File:CMPE243_S20_T2_Canster_Truck_GLCD2.jpg|thumb|600px|center| GLCD Software Simulation (Initial Iteration)]]
|
|}

=== Software Design ===
The GLCD used was created by 4DSystems, using their IDE a UI was created. Each UI component could be controlled by sending UART data targeted at the widget address.
The best part about this GLCD was that we had a lot of interactive widgets to display debugging information in real-time.
The GLCD code was divided into 3 parts:

=====Low-Level Initialization=====
Initialize the low-level hardware interfaces to send and receive data from the GLCD.
Similar to the GPS and Bluetooth, The UART GPIO was initialized (RX, TX), FreeRTOS Queue was initialized for UART Interrupt and line buffer was used to get a stream of data for parsing.

Low-level '''read''' and '''write''' commands were used as per the working of the GLCD Module.
When Reading data pertaining to a widget on the GLCD we would need to send a particular response packet.

<pre>
void lcd__read(lcd_object_e object_id, uint8_t object_index, uint8_t *response, uint16_t *response_data) {

uint8_t checksum = READ_OBJ ^ object_id ^ object_index;
uint8_t buffer[] = {READ_OBJ, object_id, object_index, checksum};

lcd__write_data(buffer, sizeof(buffer) / sizeof(uint8_t));
lcd__read_response_id(response);
lcd__read_response_data(response_data);
}
</pre>

The response_data returned contains the Widget ID as well as the current value stored on that widget.

When Writing data pertaining to a widget on a GLCD the process is similar to the above mentioned code.
<pre>
void lcd__write(lcd_object_e object_id, uint8_t object_index, uint8_t msb, uint8_t lsb, uint8_t *response) {
uint8_t checksum = WRITE_OBJ ^ object_id ^ object_index ^ msb ^ lsb;
uint8_t buffer[] = {WRITE_OBJ, object_id, object_index, msb, lsb, checksum};

lcd__write_data(buffer, sizeof(buffer) / sizeof(uint8_t));
lcd__read_response_id(response);
}
</pre>

However in this case we receive only an ACK or NACK from the system. ACK would mean that the write to GLCD widget was successful and the widget now stored appropriate values. NACK would mean that a particular error has occurred. The errors could be regarding baud rate, incorrect bit format, incorrect index values, etc.

=====GLCD Wrapper for Widgets=====
The above low-level code had generic read and write functions. However for our UI we were only using 3 Widgets. All of which had '''different Indexes''' and '''Widget IDs'''.
Therefore a very simple library was created to easily interface with those widgets
<pre>
bool lcd_wrapper__read_led(uint8_t index);
uint16_t lcd_wrapper__read_meter(uint8_t index);
uint16_t lcd_wrapper__read_leddigit(uint8_t index);

bool lcd_wrapper__write_led(uint8_t index, bool value);
bool lcd_wrapper__write_meter(uint8_t index, uint16_t value);
bool lcd_wrapper__write_leddigit(uint8_t index, uint16_t value);
</pre>

The above code is self-explanatory read and write functions for '''LED''', '''METER''', and '''LED DIGIT'''.

=====GLCD UI=====
Now that we had our low level and Widget wrapper working properly, we wanted to create our Dynamic UI as well. The code would need to be robust enough to handle any UI that we create on the GLCD which could be reflected equivalently in our C Code.

<pre>
static void lcd_ui__update_ui(void) {

lcd_wrapper__write_led(LCD_LED_DRIVER_MIA_INDEX, driver_mia_led);
lcd_wrapper__write_led(LCD_LED_SENSOR_MIA_INDEX, sensor_mia_led);
lcd_wrapper__write_led(LCD_LED_GEO_MIA_INDEX, geo_mia_led);
lcd_wrapper__write_led(LCD_LED_MOTOR_MIA_INDEX, motor_mia_led);

// kph is always in the range of 0 - 10
lcd_wrapper__write_meter(LCD_METER_KPH_INDEX, kph_meter % 11);

// These will be in the Range of 0-99
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_RPM_INDEX, rpm_leddigit % 100);
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_CURRENTDEGREE_INDEX, cdegree_leddigit % 100);
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_REQUIREDDEGREE_INDEX, rdegree_leddigit % 100);
}
</pre>

As we can see the <code>lcd_ui__update_ui</code> function was called periodically inside the 1Hz function. It updated the screen in real time based on the static values that were stored AND updated inside the LCD UI module.
The Constant INDEX values stored were directly mapped onto the Index values were received from the 4DWorkshop UI Software.

=== Technical Challenges ===

*The GLCD needs to be supplied appropriate voltage (5V) at 1A for it to work properly. The LCD does not turn on without an appropriate power supply
*The GLCD UART interface has an additional RES signal. This RES signal resets the GLCD when pulled low. When connecting the UART display it is recommended to always reset the GLCD display for proper working
*The GLCD has a latency of up to 30ms when querying and receiving data. In our case, the real-time system has hard caps on time (i.e up to 1second of delay is possible on the 1Hz function)
*This was rectified by putting the read functions (if any) inside the low priority 1Hz periodic_callback function.
*Write operations do not suffer from such a latency issue since they only send one byte (ACK or NACK) signal back.
*Fortunately most of our logic involved just a write (setting a value on the GLCD) rather than reading or querying the widget.

 

== '''Android Application''' ==
[https://gitlab.com/akhilcherukuri/can-ster_truck_application Gitlab]
=== Software Design ===

<div><ul>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android4.jpg|thumb|none|220px|Info Activity (Top)]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android7.jpg|thumb|none|220px|Info Activity (Middle)]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android5.jpg|thumb|none|220px|Info Activity (Bottom)]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android6.jpg |thumb|none|220px|Debug Activity Screen]]</li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster_Truck_Android_GIF1.gif|thumb|center|220px|App Animations]]</li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster_Truck_Android_GIF2.gif|thumb|center|220px|Live Location]]</li>
</ul></div>
The application consists of a total of 5 Activities:

=====Main Activity=====
**This is the app launch display screen
**It will check for all the required permission onStart().
**Has search button for connecting from a paired device list view
**Once device is clicked, an intent will start the Map Activity
=====Map Activity=====
* For this requirement we are using the Google Maps Fragment, for the map fragment to function we must request an API key from Google and set the key in the manifest of the application.
* Destination marker(Red Marker) is set using <code>setOnMapClickListener</code> to which the car will navigate to, the destination can be changed by clicking elsewhere on the Map Fragment. The marker can be removed using <code>setOnMarkerClickListener</code>.
* When the start button is pressed, the start command identifier along with destination latitude and longitude is sent to the car via the write thread. A background thread is started along with it to indicate the current car's position(Green Marker) along with a plotline between the current position and destination.
* When the stop button is pressed, the stop command identifier is sent to the car, to stop and turn off the car.
=====Info Activity=====
* Messages from Geological, Driver, Motor coming from CAN bus are decoded by the Sensor and Bridge controller and sent to the Android application as a string.
* The received string is parsed and categorizes the data to store it in the required textView to be displayed.
* Bluetooth status, Lidar Values, Ultrasonic Sensor Values, Motor Speed, Motor RPM, Motor PWM, Cars' current location, Compass Heading, Distance till Destination, Checkpoint Index is displayed. This was useful for debugging purposes and allowed us to avoid scanning the mounted LCD or CAN Busmaster on PC during drives.
=====Debug Activity=====
*The main function of this activity is to check all RAW RX and RAW TX messages and create a log of all the data received and sent.
=====Bluetooth Connection Service Activity=====
*This is the background activity that handles all the threads required for transmission and receiving data using Bluetooth connections. It has 3 running threads which is called inside other activities using a handler:
* Accept Thread - Listens to BluetoothServerSocket using listenUsingRfcommWithServiceRecord. In order for the RF communication socket to connect to the HC-05, we used the following <code>UUID: 00001101-0000-1000-8000-00805F9B34FB</code>. This is a generic SSP Bluetooth UUID that enables the socket to directly connected to HC-05 and maintain the connection.
* Connect Thread - Creates a Bluetooth socket using createRfcommSocketToServiceRecord
* Connected Thread - Creates socket.getInputStream(); and socket.getOutputStream(); when bytes are available in input stream it will read them into a buffer.
**All messages for activities are done by <code> Handler mHandler.obtainMessage(); mHandler.sendMessage(); </code>

'''Receieved string:'''
* A String is sent to the Bluetooth app from HC-05 and when it receives a string with identifier "$canster", the message is prased accordingly by using the string delimiter ',' and is ended by the newline character '\n' which will remove the data from StringBuffer.
* <code>Example: $canster,37.339334,-121.881123,37.338713,-121.880685,10.123,20.133,30.123,10.5,88.1,99.2,-2,1,44,7,11,22,33,-3,23\n</code>

'''Manifest:'''
<pre>
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.INTERNET" />
</pre>

'''Dependencies:'''
<pre>
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'com.google.android.gms:play-services-maps:17.0.0'
compile 'com.google.maps.android:android-maps-utils:0.4+'
implementation 'androidx.cardview:cardview:1.0.0'
implementation 'com.google.android.gms:play-services-location:17.0.0'
implementation 'androidx.appcompat:appcompat:1.1.0'
implementation 'androidx.constraintlayout:constraintlayout:1.1.3'
implementation 'com.android.support:design:28.0.0'
implementation 'androidx.navigation:navigation-fragment:2.2.1'
implementation 'androidx.navigation:navigation-ui:2.2.1'
implementation 'androidx.lifecycle:lifecycle-extensions:2.2.0'
</pre>

[[File:CMPE243_S20_T2_BLUETOOTHFLOWCHART.png|thumb|center|650px| Android Application Flowchart]]

=== Technical Challenges ===
*'''Bluetooth Discovery:''' While creating the android application, we were not able to see any Bluetooth devices in the paired device list. The problem was that for the Android versions above Lillipop we would also need location access. We have solved it by writing a function to check whether to check for permissions or not.
<pre>
private void checkBluetoothPermissions() {
Log.d(TAG, "checkBTPermissions: Checking permissions");
int permission_check = this.checkSelfPermission("Manifest.permission.ACCESS_FINE_LOCATION");
permission_check += this.checkSelfPermission("Manifest.permission.ACCESS_COARSE_LOCATION");
if (permission_check != 0) {
this.requestPermissions(new String[]{Manifest.permission.ACCESS_FINE_LOCATION, Manifest.permission.ACCESS_COARSE_LOCATION}, 1001); //Any number
}
else{
Log.d(TAG, "checkBTPermissions: No need to check permissions. SDK version < LOLLIPOP.");
}
}
</pre>
*'''Catching NULL in a StringTokenizer: ''' When sending data using Bluetooth sometimes thee app crashes. Using debug Run log in Android Studio IDE, we have found out that this is because we get <code> NullPointerException, java.util.StringTokenizer </code> error. This is mainly due to passing a null value to the StringTokenizer constructor. This problem can be avoided by after reading a line from the Bluetooth StringBuffer, we check whether it is null, before passing it to the StringTokenizer, but later on, we have preferred to use <code>split();</code> to prase the received string as StringTokenizer is now a legacy class that is retained for compatibility reasons and its use is discouraged in new code.

*'''XML Layouts: ''' Generating layouts is difficult for new android code developers, the design layouts made should be compatible for a wide range of mobile devices but using the new android libraries we have found that, the older phones then tend to have difficulty in showing the layouts correctly. We have solved this problem by learning the design commercial XML design layouts by following tutorials on Udemy and Youtube.

*'''Auto Connect''': During the first stages we have implemented Bluetooth connection via searching for all devices and clicking on the device from Listpair to connect. This has a lot of time to process all the discovered devices near range. To solve this we have hardcoded the HC-05 device address <code>00:14:03:06:02:83</code> to <code>mBluetoothAdapter.getRemoteDevice("device address")</code>.

 

== '''Management''' ==
===Git Management===

Git Management amongst 6 team members was definitely a very challenging task. Depending on our initial design we could’ve had a lot of merge conflicts. However those risks were mitigated by spending a LOT of time in the initial stages to decide our pipeline and structure.

<li>There are certain components in our system that were COMMON. For example the CAN initialization, communication and decodes were all similar for the most part between all the 4 Controllers. The utility modules used were also similar in nature</li>
<li>Thus we made a common branch that contained the templates for CAN Nodes (not Controllers), Hardware code and Utility functions.
<ol>
<li>Later this common branch was forked into an individual Controller specific branch (SENSOR, GEO, MOTOR or DRIVER).</li>
<li>Only the Logic folder contained Controller specific code, specific to that controller.</li>
</ol>
<li>This gave us a lot of flexibility since all the team members had similar APIs to work with on all 4 branches. This promoted easy understanding and learning.
<ol>
<li>Many team members frequently worked on 2 or more controllers at a time where can messages were concerned. Having a APIs also meant that just the can_handler needed to be updated regularly followed by the equivalent logic code. </li>
<li>Inside the logic folder, getters to the can node modules were frequently used.</li></ol>

An example of how one of our initial templates was setup.
<pre>
├───can_module
│ ├───can_bus_initializer
│ ├───can_constants
│ ├───can_driver_node
│ ├───can_geo_node
│ ├───can_handler
│ ├───can_motor_node
│ ├───can_sensor_node
│ └───test
├───hardware
│ ├───bt
│ ├───compass
│ ├───gps
│ ├───lcd
│ ├───lidar
│ ├───motor
│ ├───test
│ └───ultrasonic
├───logic
│ ├───driver_obstacle
│ ├───driver_state
│ ├───geo_logic
│ └───test
└───utility
├───line_buffer
└───test
</pre>

'''Challenges'''
<li>It was initially a bit of a learning curve to understand the flow of the repository</li>
<li>When using a git management system with different versions in each branch it became very tough when the number of branches suddenly exploded in size. A lot of relevant code was stuck in a lot of different branches.
<ol>
<li>This happened mainly due to assignment submissions and unclosed MRs that eventually became stale.</li>
<li>Our strategy was to abandon these MRs and keep forking from these branches without merging it back into its final controller branch.</li>
<li>The latest branches that were kept were aptly named `<controller>_bleeding_edge_dev` branches since they were never merged back from where they were forked.</li>
</ol>
<li>Since a lot of our code also depended on the DBC autogenerated code, we could not suddenly change the DBC Message names once they were established since it caused a change in the Struct name that was generated and used.
<ol>
<li>Our solution to this was to keep everything backward compatible. We added new function names without deleting old DBC messages.</li>
<li>In certain places where we wanted to modify a function name it was done one by one so that a lot of the code is not broken at one time.</li>
</ol>
<li>Common Branches eventually became stale as our progress continued on the bleeding edge branches
<ol>
<li>For example certain GPS features needed to be added which were done on the GEO_bleeding_edge_dev branch but never pushed or cherry-picked back into the COMMON branch.</li>
<li>This was a similar issue to our 2nd point but manageable since the goal of the COMMON branch was to provide a template for further work and nothing more.</li>
<li>At the end of the day each controller is its own Individual Project and while the messages between them are same. The Hardware code does not need to be same.</li>
<li>This also prompted team-members to ask if we could delete unused hardware or logic file code (which wasn’t being used and was imported from the template). This was also fine and can be done during cleanup stage. However we eventually got used to the Modular system of our project so much so that we did not worry about the additional modules that were present in each branched controller project.</li>
</ol>

 

== '''Conclusion''' ==
CMPE243 gives one of the best experiences one could ever get in their academic life. The course is designed to give an insight into how the industry functions and enhances both technical and management skills. Apart from learning how to work and implement application of CAN protocol, one can get a hands-on experience with version control, unit-testing and software design. Overall it was a very great and memorable journey.

=== Project Video ===

[https://youtu.be/zkTs8o7nB6k Youtube Video]

=== Project Source Code ===
* [https://gitlab.com/coder137/can-ster_truck GitLab Link]

=== Advise for Future Students ===
'''GENERAL:'''
* Form your team and start the project as early as you can.
* Clearly discuss what role each individual should do and ensure that progress is regularly tracked so that the team doesn't fall back on any schedule.
* Make sure your early structure of the project is decided. Before you start to write the code make sure that all the team and code guidelines are discussed. In our case we spent most of our first week deciding how we wanted to structure and design our code. This paid off in the long run since we had robust code inside one repository that could be extended efficiently.
* Make sure each module is individually testable i.e through periodic callbacks as well as unit-tests. While unit-tests can help for a lot of situations and provide a robust way to map the working of the module, it cannot simulate certain real-life scenarios. For example, Lidar buffer was constantly getting full due to the large number of incoming bytes. This caused us to have certain incorrect reading appear after a few minutes of the lidar running. Our solution was to minimize the <code>printf</code> statements inside the module that were used for debugging.
* Since lot of code and hardware integration is involved with this project, make sure testing is thoroughly and periodically done and make note of all the issues found.
'''HARDWARE:'''
* Decide on how you would power up the peripherals. We had issues with Bluetooth (not connecting), GPS (lock not happening) and LIDAR (giving incorrect values). After lot of cycles of hardware and software debugging, we found that the issue was with power. Choose wisely as to which peripherals must be connected to which power source.
* Isolate the power hungry devices to other parallel connections so that the voltage drop is not high. In our case the Graphical LCD and LIDAR were both very power hungry peripherals. The LCD used to start glitching incase there was a large voltage drop and the LIDAR used to give incorrect values or not update correctly. We solved this issue by giving the lidar a dedicated power supply.
* PCB design involves lot of hardware components. Coordinating with multiple team members and verifying each hardware connection takes quite some time. So start well ahead.
* Make sure to expose some extra GPIO and GND pins for future use.
'''MOTOR:'''
* You can use the LiPo battery to power the RPM and servo motor instead of using a separate power source. Use Vout from the ESC to get 6V.
* Start the PID control calibration early on as you will need to do extensive testing to get it working.

=== Acknowledgement ===
<HR>
Firstly we would like to express our gratitude to Professor Preetpal Kang for his guidance throughout the semester and providing us with this opportunity. We would also like to thank the ISA members Vignesh Kumar Venkateshwar and Aakash Vrajlal Chitroda for being available whenever in need and guiding us to complete the project.

== '''References''' ==
* CAN Reference [https://www.kvaser.com/about-can/can-dictionary/]
* FreeRTOS Reference [http://socialledge.com/sjsu/index.php/FreeRTOS_Tutorial]
* Git tutorial [http://socialledge.com/sjsu/index.php/Basic_Git_Tutorial]
* Unit-test reference [https://gitlab.com/sibros_public/public/-/wikis/c/unit_tests#lab-1]
* Getting started with SJ-Two [https://sjsu-dev2.readthedocs.io/en/latest/getting_started/getting_started/]

===Motor Controller===
* Traxxas User Manual: [https://images-na.ssl-images-amazon.com/images/I/D1NTpa7RNES.pdf]
* Traxxas Specification Sheet: [https://images-na.ssl-images-amazon.com/images/I/81WphBAuwIL.pdf]

===Geological Controller===
* Movable Scripts (Calculate distance, bearing and more between Latitude/Longitude points): [https://www.movable-type.co.uk/scripts/latlong.html]
* CMPS11 (I2C Configuration): [https://www.robot-electronics.co.uk/htm/cmps11i2c.htm]

===Bridge and Sensor Controller===
* [https://www.slamtec.com/en/Lidar/A1 LIDAR]
* [https://components101.com/ultrasonic-sensor-working-pinout-datasheet Ultrasonic sensor ]
===Driver and LCD Controller===
* LCD Software: [https://4dsystems.com.au/ulcd-32ptu 4Dsystems]
===Android===
* Youtube Channel: [https://www.youtube.com/channel/UCoNZZLhPuuRteu02rh7bzsw Coding with Mitch]
* Android Developers: [https://developer.android.com/guide/topics/connectivity/bluetooth Website][https://github.com/googlearchive/android-BluetoothChat Github]
* Udemy Course: [https://www.udemy.com/course/the-complete-android-oreo-developer-course/ Complete Android Oreo Developer Course]
===PCB Design===
* Design Tool: [https://easyeda.com/ EasyEDA]

S20: Canster Truck

2020-05-23T06:52:01Z

Proj user22: /* Project Video */

[[File:CMPE243_S20_T2_Canster_Truck_Logo.png|thumb|455px|caption|right|CAN-STER TRUCK LOGO]]

== '''Abstract''' ==
The Canster Truck Project is an autonomous RC car with CAN Bus interfaced controllers. The development of the RC car's subsystem modules (Interfacing of Ultrasonic Sensor, LIDAR, Bluetooth, GPS, Compass and CAN modules) was divided among six team members. The aim of the project is to develop an autonomous RC Car which can navigate from one source location to the selected destination on the app by avoiding obstacles in its path using sensors. Waypoints algorithm is used as the path finding technique.
 

== '''Introduction and Objectives''' ==

'''The project was divided into 7 modules:'''

* '''Bridge and Sensor Controller'''
* '''Motor Controller'''
* '''Geological Controller'''
* '''Driver and LCD Controller'''
* '''Hardware Integration'''
* '''Android Application'''
* '''Testing & Code Review'''

'''RC Car Objectives'''
'''1. Driver and LCD Controller''' - Handles algorithms for obstacle avoidance, route maneuvering, and waypoints
'''2. Geological Controller''' - Recieves coordinates from GPS and Heading from Compass for navigation
'''3. Motor Controller''' - Controls movements of the RC Car
'''4. Bridge and Sensor Controller''' - Detects surrounding objects and interfaces android application to controller via bluetooth
'''Team Objectives'''

[[File:CMPE243_S20_T2_High_Level_System_Diagram.png|thumb|center|800px| High Level System Diagram]]

 

== '''Team Members and Responsibilities''' ==
[[File:CMPE243_S20_T2_Canster Truck_Team.jpg|thumb|center|800px| Group Picture]]

'''Gitlab Project Link''' - [https://gitlab.com/coder137/can-ster_truck '''Canster Truck''']
 

*'''Niket Naidu''' [https://www.linkedin.com/in/niket-naidu-30090a134/ LinkedIn] [https://gitlab.com/coder137 Gitlab]
** '''Geological Controller''' : GPS, Compass, Waypoint Algorithm, Haversine and Bearing Angle logic
** '''Driver and LCD Controller''' : GLCD
** '''Bridge and Sensor Controller''' : Bluetooth
** '''Testing & Code Review'''

*'''Ganesh Ram Pamadi''' [https://www.linkedin.com/in/ganeshram93/ LinkedIn] [https://gitlab.com/ganeshram2493 Gitlab]
** '''Hardware Integration'''
** '''Testing & Code Review'''
** '''Driver Controller'''
** '''Motor Controller'''

*'''Nikhil Pabbisetty''' [https://www.linkedin.com/in/nikhilpabbisetty/ LinkedIn] [https://gitlab.com/nikhilpeoria Gitlab]
** '''Bridge and Sensor Controller'''
** '''Motor Controller'''
** '''Driver and LCD Controller'''
** '''Hardware Integration'''

*'''Akhil Cherukuri''' [https://www.linkedin.com/in/akhilcherukuri/ LinkedIn] [https://gitlab.com/akhilcherukuri Gitlab] [https://github.com/akhilcherukuri Github]
** '''Android Application'''
** '''Bridge and Sensor Controller'''

*'''Ashish Anant Ladage''' [https://www.linkedin.com/in/ashish-anant-ladage-7bb3a214b/ LinkedIn] [https://gitlab.com/ashishladage1 Gitlab]
** '''Driver and LCD Controller'''
** '''Hardware Integration'''
** '''Motor Controller'''

*'''Jesus De Haro De Reza''' [https://www.linkedin.com/in/jesus-de-haro-66342424/ LinkedIn] [https://gitlab.com/deharo27 Gitlab]
** '''Bridge and Sensor Controller'''
** '''Motor Controller'''

 

== '''Administrative Responsibilities''' ==
* '''Team Lead''' - [https://www.linkedin.com/in/niket-naidu-30090a134/ '''Niket Naidu''']
* '''Git Repository Manager''' - [https://www.linkedin.com/in/niket-naidu-30090a134/ '''Niket Naidu''']
* '''Bill Of Materials Manager''' - [https://www.linkedin.com/in/akhilcherukuri '''Akhil Cherukuri''']
* '''Wiki Report Manager''' - [https://www.linkedin.com/in/akhilcherukuri '''Akhil Cherukuri''']

 

== '''Schedule''' ==

{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-

! scope="row"| '''1'''
| style="text-align:center;" |'''02/11/2020'''
| style="text-align:center;" |'''02/17/2020'''
|
*'''Form teams and decide group name'''
*'''Review past projects'''
*'''Slack: Create project group and invite Preet'''
*'''GitLab: Create project groups repository'''
*'''Analysis of component required'''

|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''2'''
| style="text-align:center;" |'''02/18/2020'''
| style="text-align:center;" |'''02/24/2020'''
|
*'''Study CAN Communication'''
*'''Create Bill of Materials'''
*'''Order RC Car'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''3'''
| style="text-align:center;" |'''02/25/2020'''
| style="text-align:center;" |'''03/02/2020'''
|
*'''Setup team finance management using Splitwise application'''
*'''Complete Bill of Materials'''
*'''Order all other required components'''
*'''Wikipedia: Setup project report template'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''4'''
| style="text-align:center;" |'''03/03/2020'''
| style="text-align:center;" |'''03/09/2020'''
|
*'''Read the respective datasheets and manuals for each component'''
*'''Test each component for working conditions'''
|
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''5'''
| style="text-align:center;" |'''03/10/2020'''
| style="text-align:center;" |'''03/16/2020'''
|
*'''Assign team responsibilities and roles'''
*'''Setup team project management environment (ClickUp)'''
*'''Define CAN DBC'''
*'''Research GPS antennas and order'''
*'''Android: Environmental setup of Android Studio and enable version control'''
*'''Hardware : Decide PCB editing software (easyEDA)'''
*'''Hardware : Draft schematic for required PCB design'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''6'''
| style="text-align:center;" |'''03/17/2020'''
| style="text-align:center;" |'''03/23/2020'''
|
*'''Hardware : Create model of PCB''' 
*'''Android: Add a Button for changing bluetooth connection status in the application''' 
*'''Geological: Interface Compass module with SJ-2 board using I2C interface''' 
*'''Geological: Interface GPS module with SJ-2 board using the UART interface''' 
*'''Geological: Parse raw data to get meaningful values for GPS and Compass''' 
*'''Sensor: Interface and check the functionality of ultrasonic sensors to the SJ-2 board''' 
*'''Motor: Interface of Servo & DC motor to the SJ-2 board and check for basic functionality''' 
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''7'''
| style="text-align:center;" |'''03/24/2020'''
| style="text-align:center;" |'''03/30/2020'''
|
*'''Hardware : Finalize components placement on PCB.''' 
*'''Motor: Add PWM functionality and test the code on DC and servo motors''' 
*'''Sensor: Interface and check and study the output readings of Lidar sensor with SJ-2 board over UART''' 
*'''LCD Display: Explore UI designing of LCD''' 
*'''Hardware: Finalize on optimal ultrasonic sensor placements''' 
*'''Android: Initiate Bluetooth communication and show staus via text view''' 
*'''Wikipedia: Establish final wiki schedule'''
*'''Complete CAN communication format for each controller and link DBC file to the Wiki'''
*'''Complete high-level system block diagram'''
*'''Complete unit-level block diagrams'''
*'''Bridge: Interface HC-5 bluetooth module with Sj-2 board using serial communicaton'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''8'''
| style="text-align:center;" |'''03/31/2020'''
| style="text-align:center;" |'''04/06/2020'''
|
*'''Hardware: Analyze PCB model and order PCB Circuit board''' 
*'''Android: Initiate Bluetooth communication and send "Hello World".''' 
*'''Wikipedia: Start adding information/images/diagrams to the relevant sections'''
*'''Motor: Configure ESC for correct speed outcome according to frequency & PWM values''' 
*'''Motor: Finish RPM sensor hardware and software implementation and integration''' 
*'''Sensor: Read output from Lidar and setup structure for outputting for DBC''' 
*'''Geological: Implement waypoints algorithm''' 
*'''Driver: Implement obstacle avoidance algorithm''' 
*'''Bridge: Pass data such as "Hello World" from HC-05 bluetooth module to bluetooth terminal android application'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''9'''
| style="text-align:center;" |'''04/07/2020'''
| style="text-align:center;" |'''04/13/2020'''
|
*'''Hardware: Remove Unused parts from RC Car''' 
*'''Hardware: Mount PCB and 3D Parts''' 
*'''Motor: Decide different cut-off values from sensor to command right /slight right/ straight/ slight left/ left to motor.''' 
*'''Android: Embed Google Maps API for setting the car's destination.''' 
*'''LCD: Work to show RC cars live status information(battery level, current speed, long, lat, bearing, sensor data, etc)''' 
*'''Driver: Test obstacle avoidance algorithm and fine-tune sensor readings''' 
*'''Geological: Test checkpoint algorithm''' 
*'''Bridge: Establish two way communication between android application and bluetooth module''' 
*'''Update Bill of Materials for miscellaneous hardware'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''10'''
| style="text-align:center;" |'''04/14/2020'''
| style="text-align:center;" |'''04/20/2020'''
|
*'''Hardware: Integrate all hardware modules''' 
*'''LCD: Testing & Validation of the LCD UI and display vehicle status information''' 
*'''Android: Send car location to the app and checkpoints received to Geo module''' 
*'''Motor: Optimize PID control by accelerating/decelerating as instructed by Driver''' 
*'''Bridge: Configure HC-05 for auto reconnection if bluetooth communication disconnects''' 
*'''Add multiple debug messages and transmit on CAN'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''11'''
| style="text-align:center;" |'''04/21/2020'''
| style="text-align:center;" |'''04/27/2020'''
|
*'''Android: Send additional vehicle status information from RC car to the Application for display''' 
*'''Android: Finalize User Interface Design and Icon''' 
*'''Continuously test the whole system and handling of corner cases (outside).'''
*'''Finalize RC Car For Project Proto 1'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''12'''
| style="text-align:center;" |'''04/28/2020'''
| style="text-align:center;" |'''05/04/2020'''
|
*'''Gitlab: Push final code'''
*April 28th: Project Proto 1
*'''Finalize RC Car for Project Demo'''
*May 1st: Project Presentation
*'''Finalize RC Car for Project Proto 2'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''13'''
| style="text-align:center;" |'''05/05/2020'''
| style="text-align:center;" |'''05/21/2020'''
|
* '''Complete Individual Contribution Peer Grading'''
* '''Review and Complete Wiki Project Page'''
|
*'''Completed'''
*'''Completed'''
|-
|}

 

== '''Bill Of Materials''' ==
{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Item#
! scope="col"| Part Description
! scope="col"| Part Model & Vendor
! scope="col"| Quantity
! scope="col"| Cost in USD
|-
! scope="row"| 1
| '''Microcontroller Boards'''
| SJ2 Boards (Purchased from Preet Kang)
| 4
| $200.00
|-
! scope="row"| 2
| '''CAN Transceivers'''
| [https://www.waveshare.com/sn65hvd230-can-board.htm Waveshare SN65HVD230]
| 12
| $54.48
|-
! scope="row"| 3
| '''RC Car'''
| [https://www.amazon.com/Traxxas-Slash-Course-2-4GHZ-Vehicle/dp/B01DU474B0/ref=sr_1_3?ie=UTF8&qid=1474747759&sr=8-3&keywords=Traxxas+1%2F10+slash+2wd Traxxas 2WD RTR with 2.4Ghz Radio]
| 1
| $260.00
|-
! scope="row"| 4
| '''Lithium-Ion Battery'''
| [https://www.rcsuperstore.com/traxxas-7600mah-2s-7-4v-25c-id-lipo-battery-pack/ Traxxas 7600mAh 2S 7.4V 25C iD LiPo Battery Pack]
| 1
| $75.00
|-
! scope="row"| 5
| '''Lithium-Ion Battery Charger'''
| [https://www.amazon.com/Traxxas-2970-EZ-Peak-Charger-Identification/dp/B00OAFYLJC/ref=pd_bxgy_21_img_2?ie=UTF8&psc=1&refRID=JVX791WVV9Y8T9DW92KW Traxxas 2970 EZ-Peak Plus 4-Amp NiMH/LiPo Fast Charger]
| 1
| $50.00
|-
! scope="row"| 6
| '''Compass Breakout Board'''
| [https://www.dfrobot.com/product-1275.html DFRobot CMPS11 Compass]
| 1
| $29.99
|-
! scope="row"| 7
| '''Bluetooth Breakout Board'''
| [https://www.amazon.com/HC-05-Bluetooth-Pass-through-Wireless-Communication/dp/B01G9KSAF6/ref=sr_1_4?ie=UTF8&qid=1507077325&sr=8-4&keywords=arduino+bluetooth+hc-05 DSD TECH Bluetooth HC-05]
| 1
| $8.49
|-
! scope="row"| 8
| '''LIDAR Sensor'''
| [https://www.amazon.com/RPLiDAR-A1M8-Degree-Laser-Scanner/dp/B07H7X3SFF/ref=sr_1_fkmrnull_1?crid=2FSUI76G4UA8K&keywords=rplidar+a1m8+-+360+degree+laser+scanner+development+kit&qid=1552764172&s=gateway&sprefix=RPlidar%2Caps%2C263&sr=8-1-fkmrnull SEEED STUDIO RPLIDAR A1M8]
| 1
| $109.99
|-
! scope="row"| 9
| '''RPM Sensor'''
| [https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM Traxxas 6520 RPM Sensor]
| 1
| $13.70
|-
! scope="row"| 10
| '''GPS Breakout Board'''
| [https://www.adafruit.com/product/746 Adafruit Ultimate GPS Breakout v3]
| 1
| $44.30
|-
! scope="row"| 11
| '''LCD Display'''
| [https://4dsystems.com.au/ulcd-32ptu 4Dsystems 3.2 TFT-LCD ULCD-32PTU]
| 1
| $79.00
|-
! scope="row"| 12
| '''Ultrasonic Sensors'''
| [https://www.amazon.com/gp/product/B01COSN7O6/ ELEGOO HC-SR04 Ultrasonic Module]
| 5
| $12.00
|-
! scope="row"| 13
| '''GPS Antenna'''
| [https://www.amazon.com/dp/B07RRT615K/ GPS Antenna A1-UX]
| 1
| $10.98
|-
! scope="row"| 14
| '''PCB Fabrication'''
| [https://jlcpcb.com/ JLCPCB]
| 5
| $40.15
|-
! scope="row"| 15
| '''Miscellaneous'''
| [https://www.amazon.com Amazon],[https://www.mouser.com/ Mouser Electronics],[https://www.digikey.com/ Digikey],[https://anchor-electronics.com/ Anchor Electronics]
| ~
| $48.07
|-
! scope="row"|
|
|
| '''Total'''
| '''$1036.15'''
|-

|}

 

== '''Printed Circuit Board''' ==

=== Design And Architecture ===
The complete PCB (for boards and hardware peripherals) was designed using EasyEDA online software. The 4 nodes will be communicating via CAN bus and other peripherals are connected to the PCB via headers.

=== Power Section===
We have 2 power banks supplying our system. And the Servo Motor, RPM sensor and DC rear Motor (via ESC) are powered using LiPo battery (6 volts).
* Power bank #1 - Subset 2

* Power bank #2 - Subset 1, Subset 3, Bluetooth Module

'''NOTE:'''

'''Subset 1:'''
1. LIDAR
2. LCD
3. Compass

'''Subset 2:'''
1. Motor node
2. Driver node
3. BS node

'''Subset 3:'''
1. Geo node
2. Back ultrasonic sensor

=== Fabrication ===
* PCB was sent to fabrication to JLCPCB China which provided PCB with MOQ of 5 and 2 layers of PCB and common grounded the rest of the copper area.
'''DRC elements (in mils)'''
* Track Width = 12
* Clearance = 10
* Via Diameter = 24
* Via Drill Diameter = 12

=== Challenges ===
* Auto-routing gave lot of challenges (only ~60% success) and sometimes the online server even crashes and faces downtime. Even local routing had lot of issues. So make sure to plan your design accordingly.
* We started our PCB design well ahead of the project. So lot of pre-planning had to be done with regard to final hardware and placement of components in order to avoid spending extra time and money while re-ordering.
* The PCB went through a lot of internal revisions even before placing order. This was time-consuming.

'''Other hardware challenges:'''
* Figuring out why various hardware peripherals (GPS, Bluetooth, LIDAR and Ultrasonic sensor) started to malfunction (devices were on but values were either inconsistent / not occurring), took a lot of time to debug. It was due to insufficient power.

 
[[File:CMPE243 S20 T2 EasyEDA.png|1040x1200px|thumb|center|PCB Layout Design in EasyEDA]]
 
[[File:CMPE243 S20 T2 PCB SCHEMATIC.jpg|1041x550px|thumb|center|PCB Schematic]]
 
[[File:CMPE243 S20 T2 PCBFRONT.jpg|thumb|center|600px|PCB Top Layer]]
 
[[File:CMPE243 S20 T2 PCBBACK.jpg|thumb|center|600px|PCB Bottom Layer]]

 

== '''CAN Communication''' ==

=== Hardware Design ===
[[File:CMPE243_S20_T2_Canster_Truck_CANHW.png|thumb|center|770px| CAN Hardware Diagram]]

=== DBC File ===

DBC FILE: [https://gitlab.com/coder137/can-ster_truck/-/blob/dbc-improvements/projects/lpc40xx_freertos/project.dbc Gitlab]

<pre>
VERSION ""

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

BS_:

BU_: DBG DRIVER IO MOTOR SENSOR GEO

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" GEO,MOTOR,SENSOR

BO_ 101 GEO_HEARTBEAT: 1 GEO
SG_ GEO_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,MOTOR,SENSOR

BO_ 102 MOTOR_HEARTBEAT: 1 MOTOR
SG_ MOTOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,SENSOR

BO_ 103 SENSOR_HEARTBEAT: 1 SENSOR
SG_ SENSOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,MOTOR

BO_ 200 MOTOR_STEERING: 1 DRIVER
SG_ MOTOR_STEERING_direction: 0|8@1- (1,0) [-2|2] "" MOTOR

BO_ 210 DRIVER_COORDINATES: 8 DRIVER
SG_ DRIVER_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
SG_ DRIVER_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 220 MOTOR_SPEED: 1 DRIVER
SG_ MOTOR_SPEED_processed: 0|8@1- (1,0) [-3|3] "" MOTOR

BO_ 300 GEO_DEGREE: 8 GEO
SG_ GEO_DEGREE_current: 0|32@1+ (0.000001,0) [0|360] "degrees" DRIVER
SG_ GEO_DEGREE_required: 32|32@1+ (0.000001,0) [0|360] "degrees" DRIVER

BO_ 310 GEO_DESTINATION_REACHED: 1 GEO
SG_ GEO_DESTINATION_REACHED_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 400 MOTOR_SPEED_FEEDBACK: 4 MOTOR
SG_ MOTOR_SPEED_current: 0|32@1+ (0.1,0) [0|60] "kph" DRIVER

BO_ 500 SENSOR_BT_COORDINATES: 8 SENSOR
SG_ SENSOR_BT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
SG_ SENSOR_BT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 510 SENSOR_SONARS: 8 SENSOR
SG_ SENSOR_SONARS_left: 0|21@1+ (0.001,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right: 21|21@1+ (0.001,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle: 42|21@1+ (0.001,0) [0|0] "cm" DRIVER

BO_ 520 SENSOR_LIDAR: 8 SENSOR
SG_ SENSOR_LIDAR_middle: 0|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_slight_left: 16|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_slight_right: 32|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_back: 48|16@1+ (1,0) [0|0] "cm" DRIVER

BO_ 530 MOTOR_KEY: 1 SENSOR
SG_ MOTOR_KEY_val: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 900 GEO_CURRENT_COORDINATES: 8 GEO
SG_ GEO_CURRENT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" DBG
SG_ GEO_CURRENT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" DBG

BO_ 901 GEO_DISTANCE_FROM_DESTINATION: 4 GEO
SG_ GEO_distance_from_destination: 0|32@1+ (0.001,0) [0|0] "meters" DBG

BO_ 902 MOTOR_INFO_DBG: 4 MOTOR
SG_ MOTOR_INFO_DBG_rps: 0|16@1+ (1,0) [0|0] "" DBG
SG_ MOTOR_INFO_DBG_pwm: 16|16@1+ (0.001,0) [0|0] "" DBG

BO_ 903 LIPO_BATTERY_VOLTAGE_DBG: 4 MOTOR
SG_ LIPO_BATTERY_VOLTAGE_val: 0|32@1+ (0.01,0) [0|0] "volts" DBG

BO_ 904 CURRENT_CHECKPOINT_DBG: 1 GEO
SG_ CURRENT_CHECKPOINT_val: 0|8@1+ (1,0) [0|0] "" DBG

CM_ "--BU (Network Node) Information--";
CM_ BU_ DRIVER "The driver controller of the car";
CM_ BU_ GEO "The geo controller of the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";

CM_ "--BO (Message) Information--";
CM_ BO_ 100 "Driver Sync message used to synchronize the controllers";
CM_ BO_ 101 "Geo Sync message used to synchronize the controllers";
CM_ BO_ 102 "Motor Sync message used to synchronize the controllers";
CM_ BO_ 103 "Sensor Sync message used to synchronize the controllers";

CM_ BO_ 200 "Steering direction values sent by Driver Node to Motor Node";
CM_ BO_ 210 "Driver Destination coordinates sent by Driver Node";
CM_ BO_ 220 "Required motor speed computed from Driver Node to Motor Node";

CM_ BO_ 300 "Current and computer/required degree values sent by Geo Node";
CM_ BO_ 310 "Indicator signal to check if the RC car has reached the destination";

CM_ BO_ 400 "Current motor info (rps and kph) sent as feedback to the Driver Node";

CM_ BO_ 500 "Coordinate BT values (destination coordinates) sent by Sensor Node";
CM_ BO_ 510 "LIDAR - Distance from obstacle detected in each sector";
CM_ BO_ 520 "Ultrasonic Sensor - Distance from obstacle detected by each sensor";
CM_ BO_ 530 "Start/Stop signal from the Bluetooth app";

CM_ BO_ 900 "Destination coordinates for BUSMASTER debugging";
CM_ BO_ 901 "Distance from destination";
CM_ BO_ 902 "Supplied PWM value to the motor and its RPM";
CM_ BO_ 903 "LIPO Battery Voltage";
CM_ BO_ 904 "Current checkpoint of the car";

CM_ "--SG (Signal) Information for Heartbeats--";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver node";
CM_ SG_ 101 GEO_HEARTBEAT_cmd "Heartbeat command from the geological node";
CM_ SG_ 102 MOTOR_HEARTBEAT_cmd "Heartbeat command from the motor node";
CM_ SG_ 103 SENSOR_HEARTBEAT_cmd "Heartbeat command from the sensor node";

CM_ "--SG (Signal) Information for DRIVER Node--";
CM_ SG_ 200 DRIVER_STEERING_direction "Calculated Driver Steering values (-2,2) for Motor";
CM_ SG_ 210 DRIVER_COORDINATES_latitude "Destination Latitude coordinate";
CM_ SG_ 210 DRIVER_COORDINATES_longitude "Destination Longitude coordinate";
CM_ SG_ 220 MOTOR_SPEED "Calculated Driver speed values (-3,3) for Motor";

CM_ "--SG (Signal) Information for GEO Node--";
CM_ SG_ 300 GEO_DEGREE_current "Current Geo Degree relative to true north";
CM_ SG_ 300 GEO_DEGREE_required "Calculated Geo Degree computed by Haversine Formula";
CM_ SG_ 310 GEO_DESTINATION_REACHED "Indicator signal to check if the RC car has reached the destination";

CM_ "--SG (Signal) Information for MOTOR Node--";
CM_ SG_ 400 MOTOR_SPEED_FEEDBACK "Feedback speed (kph) sent by Motor Node";

CM_ "--SG (Signal) Information for SENSOR Node--";
CM_ SG_ 500 SENSOR_BT_COORDINATES_latitude "Destination Latitude received over Bluetooth";
CM_ SG_ 500 SENSOR_BT_COORDINATES_longitude "Destination Longitude received over Bluetooth";
CM_ SG_ 510 SENSOR_SONARS_left "Ultrasonic Sensor attached to the left side";
CM_ SG_ 510 SENSOR_SONARS_right "Ultrasonic Sensor attached to the right side";
CM_ SG_ 510 SENSOR_SONARS_middle "Ultrasonic Sensor attached to the middle";
CM_ SG_ 510 SENSOR_SONARS_back_left "Ultrasonic Sensor attached to the back left side";
CM_ SG_ 510 SENSOR_SONARS_back_right "Ultrasonic Sensor attached to the back right side";
CM_ SG_ 520 SENSOR_LIDAR_middle "Lidar sensing the middle sector (-15 to 15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_left "Lidar sensing the slight left sector (-45 to -15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_right "Lidar sensing the slight right sector (15 to 45 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_back "Lidar sensing the back of the car (165 to 195 degrees)";
CM_ SG_ 530 MOTOR_KEY_val "1 -> Start the motor from the app, 0 -> Stop";

CM_ SG_ 900 GEO_CURRENT_COORDINATES_latitude "Current Latitude";
CM_ SG_ 900 GEO_CURRENT_COORDINATES_longitude "Current Longitude";
CM_ SG_ 901 GEO_distance_from_destination "Distance from destination";
CM_ SG_ 902 MOTOR_INFO_DBG_rps "Current RPS value of the motor";
CM_ SG_ 902 MOTOR_INFO_DBG_pwm "Supplied motor PWM value";
CM_ SG_ 903 LIPO_BATTERY_VOLTAGE_val "LIPO Battery Voltage";
CM_ SG_ 904 CURRENT_CHECKPOINT_val "Current checkpoint of the car";

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

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

BA_ "GenMsgCycleTime" BO_ 100 1000;
BA_ "GenMsgCycleTime" BO_ 200 50;
BA_ "FieldType" SG_ 100 DRIVER_HEARTBEAT_cmd "DRIVER_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 102 GEO_HEARTBEAT_cmd "GEO_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 103 MOTOR_HEARTBEAT_cmd "MOTOR_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 104 SENSOR_HEARTBEAT_cmd "SENSOR_HEARTBEAT_cmd";

BA_ "FieldType" SG_ 200 MOTOR_STEERING "MOTOR_STEERING";
BA_ "FieldType" SG_ 230 MOTOR_SPEED_val "MOTOR_SPEED_val";
BA_ "FieldType" SG_ 310 GEO_DESTINATION_REACHED_cmd "GEO_DESTINATION_REACHED_cmd";

VAL_ 100 DRIVER_HEARTBEAT_cmd 2 "DRIVER_HEARTBEAT_cmd_REBOOT" 1 "DRIVER_HEARTBEAT_cmd_SYNC" 0 "DRIVER_HEARTBEAT_cmd_NOOP" ;
VAL_ 101 GEO_HEARTBEAT_cmd 2 "GEO_HEARTBEAT_cmd_REBOOT" 1 "GEO_HEARTBEAT_cmd_SYNC" 0 "GEO_HEARTBEAT_cmd_NOOP";
VAL_ 102 MOTOR_HEARTBEAT_cmd 20 "MOTOR_HEARTBEAT_cmd_REBOOT" 10 "MOTOR_HEARTBEAT_cmd_SYNC" 0 "MOTOR_HEARTBEAT_cmd_NOOP" ;
VAL_ 103 SENSOR_HEARTBEAT_cmd 200 "SENSOR_HEARTBEAT_cmd_REBOOT" 100 "SENSOR_HEARTBEAT_cmd_SYNC" 0 "SENSOR_HEARTBEAT_cmd_NOOP" ;

VAL_ 200 MOTOR_STEERING_direction -2 "MOTOR_STEERING_hard_left" -1 "MOTOR_STEERING_slight_left" 0 "MOTOR_STEERING_straight" 1 "MOTOR_STEERING_slight_right" 2 "MOTOR_STEERING_hard_right";
VAL_ 220 MOTOR_SPEED_processed -3 "MOTOR_SPEED_reverse_fast" -2 "MOTOR_SPEED_reverse_medium" -1 "MOTOR_SPEED_reverse_slow" 0 "MOTOR_SPEED_neutral" 1 "MOTOR_SPEED_forward_slow" 2 "MOTOR_SPEED_forward_medium" 3 "MOTOR_SPEED_forward_fast";
VAL_ 310 GEO_DESTINATION_REACHED_cmd 1 "GEO_DESTINATION_REACHED_cmd_REACHED" 0 "GEO_DESTINATION_REACHED_cmd_NOT_REACHED";
</pre>

 

== '''Motor Controller''' ==
'''[https://gitlab.com/coder137/can-ster_truck/-/tree/motor_bleeding_edge_dev GitLab Link]'''

This controller is used to control the components of the car-related to motor. We can control the speed and steering of the car having interfaced with various components with the SJ-2 board. The servo motor is controlled via PWM and is used to set the steering direction of the car. The DC motor is controlled by the Electronic Speed Controller (ESC) via PWM for speed. We read the speed of the car by using an RPM sensor. By using the RPM sensor values, a feedback loop has been designed to regulate the speed of the car. A state machine has been designed to manage the forward and backward movements of the car.
Additionally, a voltage divider circuit has been implemented to read the battery voltage. All motor functionality and CAN message communication is run at 10 Hz.

=== Hardware Design ===

[[File:CMPE243_S20_T2_Canster_Truck_Motor_Hardware.png|thumb|center|750px| Motor Hardware System]]

The following diagram details the hardware implementation of the motor module with the SJTwo board:
Hardware Interface
=====Servo Motor=====
The servo motor responds to PWM pulses. It has three pins namely Vcc, PWM Input Signal, and GND. The servo is powered using 6V from the car battery. Based on the PWM signal supplied from the SJTwo board the front wheels are turned.
[[File:CMPE243_S20_T2_Canster_Truck_Motor_1.jpg|440px|thumb|center|| Servo Motor]]
{| class="wikitable" style="text-align: center; width: 400px; height: 200px; margin: left;"
|+ Servo Motor Pin Connection
|-
! Sr. No.
! Wires - Servo Motor
! Function
|-
! 1
| PWM Connected to P2.5 || PWM Signal from Sj-2 Board
|-
! 2
| VCC || 6V supply from ESC
|-
! 3
| GND || Common Ground
|-
|}

=====Electronic Speed Controller (ESC)=====
The ESC is used to control the DC motor. It is supplied power using the 7.4 V LiPo battery. It has three pins namely Vout, PWM Input Signal, and GND. Based on the PWM input signal, the speed and forward, neutral, and backward movements of the car is changed. Vout is given to the RPM sensor and Servo motor.
[[File:CMPE243_S20_T2_Canster_Truck_Motor_2.jpg|440px|thumb|center|| Electronic Speed Controller (ESC)]]
{| class="wikitable" style="text-align: center; width: 400px; height: 200px; margin: left;"
|+ Speed Sensor Pin Connection
|-
! Sr. No.
! Wires - RPM Sensor
! Function
|-
! 1
| Signal Wire Connected to P2.0 || GPIO that supplies pulses to controller
|-
! 2
| VCC || 6V supply from ESC
|-
! 3
| GND || Common Ground
|-
|}

=====DC Motor=====
The DC motor is controlled using the ESC. It has two pins, a positive and a negative terminal. A PWM signal wire is connected to the microcontroller and the required current is provided by the LiPo battery and the ESC. The DC motor is controlled using PWM at 10Hz.

[[File:CMPE243_S20_T2_Canster_Truck_Motor_3.jpg|320px|thumb|center|| DC Motor]]
{|
|-
|
{| class="wikitable" style="text-align: center; width: 400px; height: 200px; margin-left:0px;"
|+ DC Motor Pin Connection
|-
! Sr. No.
! Wires - DC Motor
! Description
|-
! 1
| Positive Wire (already connected) || Positive Terminal
|-
! 2
| Negative Wire (already connected || Negative Terminal
|-
|}
 
{| class="wikitable" style="text-align: center; width: 400px; height: 200px;"
|+ DC Motor Configuration
|-
! Operation
! Pulse Width Range (ms)
! Duty Cycle(%)
|-
! FORWARD
| 1.51 - 2.00 || 15.1-20.0
|-
! STOP
| 1.50 || 15.0
|-
! REVERSE
| 1.00 - 1.49 || 10.0-14.9
|-
|}
|
|-
|}

Note: First calibrate the DC motor or the motor will not respond to your PWM pulses. For help with calibration go to this [https://traxxas.com/support/Programming-Your-Traxxas-Electronic-Speed-Control website]

=====RPM Sensor=====

The RPM sensor is used to get the current speed of the car. We use the info for creating a feedback loop (PID) for maintaining the speed of the car in uphill and downhill situations. The RPM sensor mounts on the rear DC motor shaft compartment with a special assembly also provided by Traxxas. The magnet which attached to the inner gear generates a pulse each rotation. The sensor works on the hall effect principle where it provides a current across its terminal when placed in a magnet's field. The RPM sensor has three pins namely Vcc, Signal, and GND.

[[File:CMPE243_S20_T2_Canster_Truck_Motor_4.jpg|440px|thumb|center|| RPM Sensor]]

{| class="wikitable" style="text-align: center; width: 400px; height: 200px; margin: left;"
|+ Speed Sensor Pin Connection
|-
! Sr. No.
! Wires - RPM Sensor
! Function
|-
! 1
| Signal Wire Connected to P2.2 || GPIO that supplies pulses to controller
|-
! 2
| VCC || 6V supply from ESC
|-
! 3
| GND || Common Ground
|-
|}

=== Software Design ===

The software for the motor node was divided into multiple files and made modular to improve readability and understanding of the complex logic involved. The main code modules are for:
*Servo Motor
*Electronic Speed Controller
*RPM Sensor
*Motor Wrapper
*Battery Voltage

The motor wrapper module is used to wrap all the code from the esc, servo, and rpm modules into simple to use functions to be called in the periodic tasks.
=====Servo Motor=====
It uses the steering value sent from the driver (-2 to 2) and matches it to the appropriate PWM value for steering. This code module is run at 10Hz.
<pre>
void servo__steer_processor(int16_t steering_value) {
switch (steering_value) {
case MOTOR_STEERING_hard_left:
servo__steer_hard_left();
break;
case MOTOR_STEERING_slight_left:
servo__steer_soft_left();
break;
case MOTOR_STEERING_straight:
servo__steer_straight();
break;
case MOTOR_STEERING_slight_right:
servo__steer_soft_right();
break;
case MOTOR_STEERING_hard_right:
servo__steer_hard_right();
break;
default:
printf("\nDid not receive steering value");
}
}
</pre>
=====Electronic Speed Controller=====

This code module is used to control the DC motor. It receives the motor direction value from the driver and sets the appropriate PWM value. Based on the value the motor is commanded to move the car forward or backwards. A switch case is implemented to set PWM values for movement in different directions along with different speeds.
<pre>
void esc__direction_processor(int16_t direction_value) {
desired_direction_value = direction_value;
switch (direction_value) {
case MOTOR_SPEED_reverse_fast:
esc__reverse_fast();
break;
case MOTOR_SPEED_reverse_medium:
esc__reverse_medium();
break;
case MOTOR_SPEED_reverse_slow:
esc__reverse_slow();
break;
case MOTOR_SPEED_neutral:
esc__neutral();
break;
case MOTOR_SPEED_forward_slow:
esc__forward_slow();
break;
case MOTOR_SPEED_forward_medium:
esc__forward_medium();
break;
case MOTOR_SPEED_forward_fast:
esc__forward_fast();
break;

default:
printf("\nDid not receive direction and speed value");
}
}
</pre>

There is also a feedback loop to control the speed. The ESC code depends on the rpm sensor code for the current speed values.
<pre>
double current_speed = get_speed_kph();
double desired_speed = desired_speed_kph;
float adjusted_duty_cycle = 0.0;
adjusted_duty_cycle = duty_cycle + (speed_to_pwm_adjustment(desired_speed, current_speed));
</pre>

[[File:CMPE243_S20_T2_Canster_Truck_Motor1.png|thumb|center|500px| Feedback Loop for Motor Speed]]

=====RPM Sensor=====
This code module is used to get current speed data from the RPM sensor. It is based on interrupts. When the wheel rotates once, we get one pulse due to the magnet installed. This pulse generates a falling edge interrupt during which we increment the pulse counter. Since, this code is run at 1Hz we collect the number of pulses generated every one second. This gives us the number of rotations per second using which we can calculate the speed in kph.
<pre>
float rpm__calculate_speed_kph() {
uint16_t rotation_per_sec = pulse_count;
pulse_count = 0;
speed_kph = ((CIRCUMFERENCE_METER * rotation_per_sec) * (MPS_TO_KPH_CONVERSION_FACTOR)) / GEAR_RATIO;
return speed_kph;
}
</pre>

=====Motor Wrapper=====
As mentioned above, the main function of this code module is to wrap all the other code modules and call the right functions at the appropriate frequency. The motor wrapper code also includes a state machine for ensuring a smooth transition between forward to backward state and vice versa. In order to achieve a smooth transition, a series of PWM pulses must be generated at the right time. For example, when the motor is moving from forward to backward state, a reverse value must be given first followed by at least three neutral values, and then continue with reverse values.

[[File:CMPE243_S20_T2_Canster_Truck_Motor2.png|thumb|center|500px| State Machine Flowchart for Motor Movements]]

=====LiPo Battery Voltage=====

The LiPo Battery Voltage was calculated using ADC in Burst Mode. A LiPo Hardware module was created for the same which contained two functions, <code>lipo__init</code> and <code>lipo__get_voltage</code>.

The voltage divider circuit is stepped down from 7.4V to 2.1V using 10K and 4K Resistor pair.
[[File:CMPE243_S20_T2_Canster Truck_Motor_Voltage_Regulator.png|thumb|center|400px| Voltage Regulator]]
'''LiPo Initialization'''

The LiPo Initialization phase initializes the ADC, Enables Burst mode on the ADC pins and configures the Alternate Function Registers for the same.

'''Getting LiPo Voltage'''

We read the raw ADC value from the LPC Hardware register. This value will be from 0 - 3.3V. However due to our voltage divider configuration the max voltage that we should theoretically get is 2.1V. This means that 2.1V corresponds to 7.4V of the LIPO Battery voltage.

The formula used is
<code>(raw_adc_value * MAX_LIPO_BATTERY_VOLTAGE_VALUE) / MAX_LIPO_ADC_VALUE</code>

=== Technical Challenges ===
<li>Changing movements of the car from Forward to Backward and vice versa
If you just change the PWM value from say 16 (Forward) to 14(Backward), the DC motor will just stop and will not make wheels turn reverse. We discovered this problem quite late as during the initial testing we had always run the car from the start with either forward or reverse but never tried changing the direction during run-time.
 
Solution: The motor requires a series of PWM pulses which is specific to the car to transition from forward mode to reverse mode. In our case we had to give the PWM pulses in the following sequence. Suppose,
<ol>
<li> Forward (16) (callback_count = 0)</li>
<li> Forward (16) (callback_count = 1)</li>
<li> Reverse (14) (callback_count = 2)</li>
<li> Neutral (15) (callback_count = 3)</li>
<li> Neutral (15) (callback_count = 4)</li>
<li> Neutral (15) (callback_count = 5)</li>
<li> Reverse (14) (callback_count = 6)</li>
<li> Continue reverse</li>
</ol>
Similarly, the reverse to forward can also be implemented.
<li>DC motor shooting off when there is an improper ground connection
When we connected the battery voltage circuit for reading the voltage from the battery, the motor would randomly shoot off every now and then.
 
Solution: Connect the voltage divider circuit to the common ground rather than taking the ground from the ESC.</li>

 

== '''Geological Controller''' ==
'''[https://gitlab.com/coder137/can-ster_truck/-/tree/geo_bleeding_edge_dev_waypoints GitLab Link]'''

===Messages===
*GEO_HEARTBEAT: Used to check for MIA by other nodes. Highest priority message for GEO Node

*GEO_DEGREE: Sends the current degree relative to the North Pole computed by the Compass and the Required degree relative to the North Pole computed by Bearing Angle using the Current Coordinate and Destination Coordinate.

*GEO_DESTINATION_REACHED: Sets a flag, 0 for destination not reached and 1 for destination reached

*GEO_CURRENT_COORDINATES: Debug Message used to send the Current GPS Coordinates

*GEO_DISTANCE_FROM_DESTINATION: Debug message used to send the Distance from Destination

*CURRENT_CHECKPOINT_DBG: Debug message used to check which checkpoint is being navigated to

=== Hardware Design ===

[[File:CMPE243_S20_T2_GEO1.png|thumb|center|650px| Geological Diagram]]

=== Software Design ===
=====Overview=====
*Inside the `periodic_callback__initialize`
**Initialize the CAN BUS
**Initialize the GPS

*Inside the `periodic_callback__1hz`
**Handle all MIA (from other Nodes)
**Update GPS LED when init and in case of failure
**Compute the GEO logic for Waypoints algorithm once every second (1000 ms)

*Inside the `periodic_callback__10hz`
**Handle CAN Incoming messages (Decode)
**Transmit CAN Geo messages (Encode and send)
**Compute the GPS Coordinate

=====Compass I2C Driver=====
An online datasheet resource was used to work with the Compass ([https://www.robot-electronics.co.uk/htm/cmps11i2c.htm CMPS11 Datasheet])
Initially the Compass I2C Driver was tested using the Terminal I2C Helper built by our Professor Preetpal Kang. Using this resource we were quickly able to read various I2C Registers and display it onto the terminal.

For our project the only required part of the Compass was the 16-bit Compass Bearing value (0-3599) i.e 0-359.9 degree values. These values were stored in the 2nd and 3rd register (Register 2 being the High Byte).
Once the raw data was received over I2C we could easily combine the data

<pre>
uint16_t bearing_value = (Reg2 << 8) | Reg3;
float rval = bearing_value / 10.0;
return rval;
</pre>
The returned value were transmitted to the Driver Node to compute its steering based on the required Bearing Angle.

=====GPS Initialization=====
GPS Initialization activates the Hardware GPIO (RX and TX), FreeRTOS Queue for UART Interrupts (UART Module) and Line Buffer Module to parse each GPS line.

=====GPS Data Parsing=====
The GPS Hardware module transmits an NMEA string over UART to the SJTwo Board. We read each character one by one and add it to the Line Buffer module.
Inside its computation loop, the Line Buffer module checks if a newline character has been received.
When a newline character has been received the entire string is extracted from the line buffer module and parsed according to its identifier ($GPRMC, $GPGGA) received and parsed into individual tokens.
For our purposes the $GPRMC NMEA string was the most appropriate and it helped us extract the Current Latitude Longitude as well as the Valid/Invalid tag for the Canster Truck.

=====GPS LED Indication for debugging=====

A simple module that checks for the GPRMC GPS Message and extracts the A or V valid (Tag). If $GPRMC NMEA string is valid, LED is set, else LED is reset. This gives us onsite debugging capabilities to know if GPS has locked onto a satellite signal.

=====GEO Logic Module Computation=====
The GEO Logic Module computes the Bearing Angle, Haversine Distance as well as the Waypoints algorithm.

'''Bearing Angle:'''

<code>
θ = atan2( sin Δλ ⋅ cos φ2 , cos φ1 ⋅ sin φ2 − sin φ1 ⋅ cos φ2 ⋅ cos Δλ )
</code>

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

Since atan2 returns values in the range -π ... +π (that is, -180° ... +180°), to normalize the result to a compass bearing (in the range 0° ... 360°, with −ve values transformed into the range 180° ... 360°), convert to degrees and then use (θ+360) % 360, where % is (floating point) modulo.
For final bearing, simply take the initial bearing from the endpoint to the start point and reverse it (using θ = (θ+180) % 360).

The above article reference gives us the required bearing angle that our car must align itself to, to reach a particular destination coordinate from its current coordinate.
The Steering of the vehicle depends on the above-computed angle values.

'''Haversine Distance Formula:'''

This uses the ‘haversine’ formula to calculate the great-circle distance between two points – that is, the shortest distance over the earth’s surface – giving an ‘as-the-crow-flies’ distance between the points (ignoring any hills they fly over, of course!).

<code>
a = sin²(Δφ/2) + cos φ1 ⋅ cos φ2 ⋅ sin²(Δλ/2)

c = 2 ⋅ atan2( √a, √(1−a) )

d = R ⋅ c
</code>

where φ is latitude, λ is longitude, R is earth’s radius (mean radius = 6,371km);
note that angles need to be in radians to pass to trig functions!

The above formula is used to calculate the distance between the source coordinate (received via GPS) and the destination coordinate.
Later this was used to compute the distance between source coordinate and each individual checkpoint to traverse the shortest distance.

'''Waypoints Algorithm:'''

The Waypoints algorithm that was chosen was a slightly modified version of Djikstra’s Algorithm.
3 values were calculated before the final computation

* Distance between source and final destination (DISTsd)
* Distance between source and each individual checkpoint (DISTsc)
* Distance between each individual checkpoint and the final destination. (DISTcd)

If '''DISTsd''' was lesser than '''DISTcd''', this checkpoint was discarded (we continue in the loop). Since we would be moving in the opposite direction, rather than towards the final destination.

If '''DISTsd''' was greater than '''DISTcd''', then we checked the nearest checkpoint to the source.
The minimum value was set initial that was equal to '''DISTsd'''.

If '''DISTsc''' was lesser than the minimum value stored, '''DISTsc''' would become the new minimum value, and the checkpoint index and coordinates would be appropriately stored and returned from the function.

In this way we would navigate to the nearest checkpoint from the source, while also making sure NOT to travel in the opposite direction.
This logic is recomputed only when we reach the checkpoint selected and the algorithm runs again to find the next checkpoint that we need to navigate to.

=====CAN Decode Destination Coordinates=====
Destination Coordinates are received from the Bridge and Sensor Node and transmitted over the CAN Bus. The value is decoded and stored in the GEO Logic Module.
This is a very important value since our entire GEO Logic calculations are based on the Destination Coordinate.

=====CAN Encode and Send=====

The main messages that were transmitter are
#Geo Degree
#Geo Destination Reached
#Distance from Destination Debug and Checkpoint Index debug

'''Geo Degree Computation as per Waypoints Algorithm:'''

Geo Degree was computed as per the current coordinates and the most recently computed checkpoint coordinates. This bearing angle calculation w.r.t computed checkpoint would continue till we do not reach that particular checkpoint.
Once we reach the computed checkpoint, Waypoint algorithm is recomputed as per the process mentioned above and the algorithm runs again.

'''Geo Destination Reached:'''

An Area of around 4 meters was set around the destination coordinate to check if the destination had been reached.
This measurement was taken into consideration to allow for the loss in precision when transmitting data over CAN as well as any irregularities that might occur when getting values from the GPS.
Having an area of 4 meters was very accurate for all of our test runs.

'''Geo Distance from Destination Debug and Checkpoint Index Debug:'''

Getting debug information was very critical to speed up our development process. In this case we could actively see if our algorithm worked properly.
The Geo Distance from Destination was used to see if we were moving closer to our destination or veering further away from it.
The Checkpoint Index was used to see which checkpoint index we were traveling to. By knowing the placements of the Individual checkpoints we could manually as well as programmatically (via Android application) verify the working of our Canster Truck.

=== Technical Challenges ===
#DBC Challenge for GEO Coordinates -> Could not encode more than 5-6 decimal places at a time, on later investigation we found that the 10000 is an int value, however 100000 overflows the int value.
#Creating an efficient algorithm for Waypoints, O(n) complexity.
#Getting appropriate fixes for GPS when not in a completely open space.
#GPS used to fluctuate or stop giving values when Battery voltage went below a particular threshold. Always supply 3.3V constantly at a good amperage.

 

== '''Sensor [Bridge and Sensor Controller]''' ==
'''[https://gitlab.com/coder137/can-ster_truck/-/tree/sensor_bleeding_edge_dev GitLab]'''
==='''Ultrasonic Sensor'''===
====Hardware Design====
This sensor uses an ultrasonic beam to measure the distances. Based on the time taken between when the beam is sent and received back to the sensor, the distance is calculated in the node.
Apart from 5v and GND, this sensor has 2 pins ECHO and TRIG which are interfaced with the SJ-Two board via GPIO.

[[File:CMPE243_S20_T2_CansterTruck_ultrasonic_sensor.jpg|thumb|center|300px| Ultrasonic Sensor Diagram]]

====Software Design====
* Init the GPIO pin connected to TRIG of the sensor as output and for ECHO as an input port.
* Attach the interrupt on the ECHO input port.
* Store the system_clock_count before setting the trigger pulse and then set the pulse. Also keep monitoring the input port.
* Take the system_clock_count at the instant of receiving the interrupt.
Distance = (system_clock_count_at_trig - system_clock_count_after_at_echo) / 57.14

==='''Lidar Sensor'''===
====Hardware Design====
The RPLidar sensor can be powered from a 5v source and uses UART communication to receive commands and transmit data. It has seven pins to interface with. Two sets of the pins (four total) are for power and ground. The remaining three are for UART receive and transmit, and for making the lidar’s motor spin.

[[File:CMPE243_S20_T2_Canster_Truck_RPLidar_A1.JPG|thumb|center|300px| RPLidar A1]]

====Software Design====
In terms of the lidar, the SJ2 initializes GPIO, UART, and memory for storing the measurement values. After initialization, the command to begin scanning is sent. Here, we wait for the lidar to send a response packet, letting the host (SJ2 board) know it received the command. The response packet the lidar sends will be 7 bytes. If the correct 7 bytes are not received, the command will be sent again.

[[File:CMPE243_S20_T2_Canster Truck_Lidar_flow.jpeg|thumb|center|200px| Lidar Flow]]

Following the response packet, the lidar begins sending 5-byte measurement data. Each sample contains a distance measurement (in millimeters) and the angle (with respect to the lidar) in which it was taken. The data packet structure is shown in the following figure. In addition to containing the distance and angle, the packet includes a quality value, to indicate the reliability of the measurement, and three check bits (S, ~S, and C). As the data is received via UART, we wait until we have 5 bytes before continuing to process. Before processing the 5 bytes after receiving them, the check bits are confirmed to be correct. If they are incorrect, it will not be processed and we will wait for another sample to be received.

[[File:CMPE243_S20_T2_Canster Truck_DataPacketStructure.JPG|thumb|center|200px| Data Packet Structure]]

In the case the sample is correct, each measurement value that is in a direction of interest will be placed in an array designated to one of four directions (left, right, front, rear). Each of these directions have their own sector in the lidar’s 360-degree view.
*Right sector: 11° - 30°
*Rear sector: 170° - 190°
*Left sector: 330° - 349°
*Front sector: 350° - 370° (or 10°)

The arrays mentioned will hold roughly 20 measurements, which are every degree in the sector. In the event, objects are too far to measure, the lidar will report 0 mm. distance. Since there is no measurable obstacle, a “large” distance value of 3000 mm. is placed in the array. The smallest distance value will be taken from each array and reported to the driver node for obstacle avoidance.

=== Technical Challenges ===
====Ultrasonic Sensor====
*'''Power issue''' The pulses were getting triggered incorrectly and it took a while to figure out that it was due to insufficient power.

====LIDAR====
*'''Datasheet not 100% clear:''' The correct datasheet for the was a bit difficult to obtain, and the manufacturer needed to be contacted. The first document found online was high level and general information about the sensor, but the manufacturer did provide another document that contained the information of the commands and responses to and from the lidar, and their packet structure. The documents did not clearly state the angles with respect to the lidar are fixed, which left me wondering if the lidar will think the direction it is facing when powered on will become the new “zeroth” angle.

*'''UART Buffer Overflow:''' When first interfacing with the sensor, the incoming bytes of the lidar were printed on to the terminal to make sure there was a response and to make sense of the information. Since the command we sent results in 5 bytes of data per measurement samples from the lidar and the lidar measured 2000 times per second, there are will be roughly 10k Bytes per second of data incoming that need to be handled continuously. With an improperly sized UART buffer and print statements it is guaranteed to occur, making the lidar data look like random values.

*'''Proper Parsing of Measurement Data:''' After sending a command to the lidar, the sensor will send a response packet, followed by the measurement data. The initial response from the lidar is a 7-byte packet, followed by continuous 5-byte measurement samples. I needed to make sure however I handled the response would be independent of how the measurement is handled, so as not to create a potential unwanted offset when receiving measurements.

*'''Object Detection with Received Data:''' Once proper communication was set up with the lidar and measurement data was getting decoded, there needed to be a way to measure when obstacles were present. If ~360 measurements are handled entirely independently from one another, it could become a complex and confusing code. To achieve a simple approach, four sectors about 20 degrees in size were used to represent the front, left, right, and rear directions.

*'''Bugs in Code:''' When first implementing the code, there were a few bugs from typos, incorrect numbers, and some faulty logic that were found with the use of unit testing. Unit testing helped find these issues and verified the logic was correct, and I would say gave me 90% confidence in my lidar handling.

 

== '''Bluetooth Module [Bridge and Sensor Controller]'''==

Bridge functionality of the Bridge and Sensor Controller is to establish wireless communication between the SJ-2 Board and the android mobile device using the HC-05 Bluetooth module. The Bridge controller will be receiving start command with destination GEO coordinates and stop command. The Bridge controller will be transmitting the required sensor data and debug information to be displayed on the android application.

[[File:CMPE243_S20_T2_BRIDGE.png|thumb|center|500px| Bridge Diagram]]

==== Software Design ====

'''Low-Level Layer'''

In this layer, similar to the GPS the UART GPIO was initialized (RX, TX), FreeRTOS Queue was initialized for UART Interrupts and the line buffer module was initialized to parse strings.

Two basic functions <code>bt__read</code> and <code>bt__write</code> were implemented.
As the name suggested, <code>bt__write</code> took a string as its input parameter and transmitted that data to the Android application. <code>bt__read</code> stored the incoming characters into the line buffer, parsed the line received into its identifier and tokens, and invoked a callback function.

Since this was a low-level layer the User would not be directly invoking this library. Instead a '''Bluetooth Wrapper''' module was created which would be invoked and used by the user.

'''Application Layer'''

The Bluetooth Wrapper module had the appropriate <code>read_once</code> and <code>write_once</code> functions.

The <code>read_once</code> function internally just called the <code>bt__read</code> function. All of the decodings was done inside the Callback Function.
To get the Destination coordinate the string received from the Android Application was in the form of
<code>$loc,<destination_latitude>,<destination_longitude>.</code>
Upon receiving this data we parsed the destination_latitude and destination_longitude, which could later be accessed using getters.
We also set a start flag to notify the Driver Node that destination has been received and we can start steering towards our checkpoints.

Another command implemented was the stop command.
<code>$stop</code>
This was used to send a stop flag to the Driver node.

The <code>write_once</code> function used the getter methods from each CAN Decode message and update its internal state variables. A CSV String was created using the <code>$canster</code> identifier and various debugging points were appended to this message using a comma.
On the Android application side this CSV string was tokenized and displayed onto the Application Debug screen appropriately.

==== Technical Challenges ====

'''Bluetooth peripheral not turning on'''
* We initially connected the Bluetooth module directly to the SJ-Two board with (Vcc = 3.3v). But it was not giving only 2.7v and hence the device did not turn on.
* We had to connect it to external power source to make it function without hassles.

 

== '''Driver [Driver and LCD Controller]''' ==
'''[https://gitlab.com/coder137/can-ster_truck/-/tree/driver_bleeding_edge_dev GitLab]'''

=== Software Design ===

[[File:CMPE243_S20_T2_Canster Truck_Driver_Flowchart.png|thumb|center|750px|Driver Flowchart]]

The above block diagram explains the process flow of obstacle detection for the car. The LIDAR detects
the obstacle and depending on the distance of obstacle the car takes a slight right and slight left or a
hard right and hard left. The state of the car also depends on the value of the LIDAR and ultrasonic sensor.
The loose ends of the LIDAR for the reverse condition are checked by the ultrasonic sensors. The
The ultrasonic sensor works on the principle of trigger and echo and can detect the obstacles very close by.
The range of the Ultrasonic sensor is lower than the LIDAR. Finally, if no obstacle is detected the car goes
straight until the destination is reached. The speed of the car is also various when an obstacle is detected to
avoid the crash and the car’s smooth transition from one state to another. The key to the android
application controls the start and stop the process of the car. If the key is not pressed, then the stays in the

neutral state. The speed of the car is controlled by the changing duty cycle of the input voltage. There
are seven-speed levels in which the motor can run on. These speed levels are Forward Slow, Medium,
Fast, Reverse Slow, Medium, Fast, and Neutral. The Neutral is the stop condition with a 0% duty cycle.

=== Technical Challenges ===

Technical Challenges faced during obstacle detection:

*Due to dimensions of the car and for the perfect obstacle avoidance the values of 100cm and 150cm had to be selected for the turning radius. Hence, it is very important to calibrate these values appropriately, as these values will be unique for different car designs.
*For a situation, where even if the lidar doesn’t detect any obstacle at the middle, the car must take a slight right or a slight left as per our design. This is the case where the obstacle can be a moving one and that is why the lidar middle couldn’t detect it.

 

== '''LCD [Driver and LCD Controller]''' ==
=== Hardware Design ===
[[File:CMPE243_S20_T2_Canster_Truck_LCD_Diagram.png|thumb|600px|center| LCD Design]]
{|style="text-align: center; width: 400px; height: 200px; margin: auto;"
|
[[File:CMPE243_S20_T2_Canster_Truck_GLCD.jpg|thumb|200px|center| GLCD Hardware]]
||
[[File:CMPE243_S20_T2_Canster_Truck_GLCD2.jpg|thumb|600px|center| GLCD Software Simulation (Initial Iteration)]]
|
|}

=== Software Design ===
The GLCD used was created by 4DSystems, using their IDE a UI was created. Each UI component could be controlled by sending UART data targeted at the widget address.
The best part about this GLCD was that we had a lot of interactive widgets to display debugging information in real-time.
The GLCD code was divided into 3 parts:

=====Low-Level Initialization=====
Initialize the low-level hardware interfaces to send and receive data from the GLCD.
Similar to the GPS and Bluetooth, The UART GPIO was initialized (RX, TX), FreeRTOS Queue was initialized for UART Interrupt and line buffer was used to get a stream of data for parsing.

Low-level '''read''' and '''write''' commands were used as per the working of the GLCD Module.
When Reading data pertaining to a widget on the GLCD we would need to send a particular response packet.

<pre>
void lcd__read(lcd_object_e object_id, uint8_t object_index, uint8_t *response, uint16_t *response_data) {

uint8_t checksum = READ_OBJ ^ object_id ^ object_index;
uint8_t buffer[] = {READ_OBJ, object_id, object_index, checksum};

lcd__write_data(buffer, sizeof(buffer) / sizeof(uint8_t));
lcd__read_response_id(response);
lcd__read_response_data(response_data);
}
</pre>

The response_data returned contains the Widget ID as well as the current value stored on that widget.

When Writing data pertaining to a widget on a GLCD the process is similar to the above mentioned code.
<pre>
void lcd__write(lcd_object_e object_id, uint8_t object_index, uint8_t msb, uint8_t lsb, uint8_t *response) {
uint8_t checksum = WRITE_OBJ ^ object_id ^ object_index ^ msb ^ lsb;
uint8_t buffer[] = {WRITE_OBJ, object_id, object_index, msb, lsb, checksum};

lcd__write_data(buffer, sizeof(buffer) / sizeof(uint8_t));
lcd__read_response_id(response);
}
</pre>

However in this case we receive only an ACK or NACK from the system. ACK would mean that the write to GLCD widget was successful and the widget now stored appropriate values. NACK would mean that a particular error has occurred. The errors could be regarding baud rate, incorrect bit format, incorrect index values, etc.

=====GLCD Wrapper for Widgets=====
The above low-level code had generic read and write functions. However for our UI we were only using 3 Widgets. All of which had '''different Indexes''' and '''Widget IDs'''.
Therefore a very simple library was created to easily interface with those widgets
<pre>
bool lcd_wrapper__read_led(uint8_t index);
uint16_t lcd_wrapper__read_meter(uint8_t index);
uint16_t lcd_wrapper__read_leddigit(uint8_t index);

bool lcd_wrapper__write_led(uint8_t index, bool value);
bool lcd_wrapper__write_meter(uint8_t index, uint16_t value);
bool lcd_wrapper__write_leddigit(uint8_t index, uint16_t value);
</pre>

The above code is self-explanatory read and write functions for '''LED''', '''METER''', and '''LED DIGIT'''.

=====GLCD UI=====
Now that we had our low level and Widget wrapper working properly, we wanted to create our Dynamic UI as well. The code would need to be robust enough to handle any UI that we create on the GLCD which could be reflected equivalently in our C Code.

<pre>
static void lcd_ui__update_ui(void) {

lcd_wrapper__write_led(LCD_LED_DRIVER_MIA_INDEX, driver_mia_led);
lcd_wrapper__write_led(LCD_LED_SENSOR_MIA_INDEX, sensor_mia_led);
lcd_wrapper__write_led(LCD_LED_GEO_MIA_INDEX, geo_mia_led);
lcd_wrapper__write_led(LCD_LED_MOTOR_MIA_INDEX, motor_mia_led);

// kph is always in the range of 0 - 10
lcd_wrapper__write_meter(LCD_METER_KPH_INDEX, kph_meter % 11);

// These will be in the Range of 0-99
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_RPM_INDEX, rpm_leddigit % 100);
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_CURRENTDEGREE_INDEX, cdegree_leddigit % 100);
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_REQUIREDDEGREE_INDEX, rdegree_leddigit % 100);
}
</pre>

As we can see the <code>lcd_ui__update_ui</code> function was called periodically inside the 1Hz function. It updated the screen in real time based on the static values that were stored AND updated inside the LCD UI module.
The Constant INDEX values stored were directly mapped onto the Index values were received from the 4DWorkshop UI Software.

=== Technical Challenges ===

*The GLCD needs to be supplied appropriate voltage (5V) at 1A for it to work properly. The LCD does not turn on without an appropriate power supply
*The GLCD UART interface has an additional RES signal. This RES signal resets the GLCD when pulled low. When connecting the UART display it is recommended to always reset the GLCD display for proper working
*The GLCD has a latency of up to 30ms when querying and receiving data. In our case, the real-time system has hard caps on time (i.e up to 1second of delay is possible on the 1Hz function)
*This was rectified by putting the read functions (if any) inside the low priority 1Hz periodic_callback function.
*Write operations do not suffer from such a latency issue since they only send one byte (ACK or NACK) signal back.
*Fortunately most of our logic involved just a write (setting a value on the GLCD) rather than reading or querying the widget.

 

== '''Android Application''' ==
[https://gitlab.com/akhilcherukuri/can-ster_truck_application Gitlab]
=== Software Design ===

<div><ul>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android4.jpg|thumb|none|220px|Info Activity (Top)]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android7.jpg|thumb|none|220px|Info Activity (Middle)]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android5.jpg|thumb|none|220px|Info Activity (Bottom)]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android6.jpg |thumb|none|220px|Debug Activity Screen]]</li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster_Truck_Android_GIF1.gif|thumb|center|220px|App Animations]]</li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster_Truck_Android_GIF2.gif|thumb|center|220px|Live Location]]</li>
</ul></div>
The application consists of a total of 5 Activities:

=====Main Activity=====
**This is the app launch display screen
**It will check for all the required permission onStart().
**Has search button for connecting from a paired device list view
**Once device is clicked, an intent will start the Map Activity
=====Map Activity=====
* For this requirement we are using the Google Maps Fragment, for the map fragment to function we must request an API key from Google and set the key in the manifest of the application.
* Destination marker(Red Marker) is set using <code>setOnMapClickListener</code> to which the car will navigate to, the destination can be changed by clicking elsewhere on the Map Fragment. The marker can be removed using <code>setOnMarkerClickListener</code>.
* When the start button is pressed, the start command identifier along with destination latitude and longitude is sent to the car via the write thread. A background thread is started along with it to indicate the current car's position(Green Marker) along with a plotline between the current position and destination.
* When the stop button is pressed, the stop command identifier is sent to the car, to stop and turn off the car.
=====Info Activity=====
* Messages from Geological, Driver, Motor coming from CAN bus are decoded by the Sensor and Bridge controller and sent to the Android application as a string.
* The received string is parsed and categorizes the data to store it in the required textView to be displayed.
* Bluetooth status, Lidar Values, Ultrasonic Sensor Values, Motor Speed, Motor RPM, Motor PWM, Cars' current location, Compass Heading, Distance till Destination, Checkpoint Index is displayed. This was useful for debugging purposes and allowed us to avoid scanning the mounted LCD or CAN Busmaster on PC during drives.
=====Debug Activity=====
*The main function of this activity is to check all RAW RX and RAW TX messages and create a log of all the data received and sent.
=====Bluetooth Connection Service Activity=====
*This is the background activity that handles all the threads required for transmission and receiving data using Bluetooth connections. It has 3 running threads which is called inside other activities using a handler:
* Accept Thread - Listens to BluetoothServerSocket using listenUsingRfcommWithServiceRecord. In order for the RF communication socket to connect to the HC-05, we used the following <code>UUID: 00001101-0000-1000-8000-00805F9B34FB</code>. This is a generic SSP Bluetooth UUID that enables the socket to directly connected to HC-05 and maintain the connection.
* Connect Thread - Creates a Bluetooth socket using createRfcommSocketToServiceRecord
* Connected Thread - Creates socket.getInputStream(); and socket.getOutputStream(); when bytes are available in input stream it will read them into a buffer.
**All messages for activities are done by <code> Handler mHandler.obtainMessage(); mHandler.sendMessage(); </code>

'''Receieved string:'''
* A String is sent to the Bluetooth app from HC-05 and when it receives a string with identifier "$canster", the message is prased accordingly by using the string delimiter ',' and is ended by the newline character '\n' which will remove the data from StringBuffer.
* <code>Example: $canster,37.339334,-121.881123,37.338713,-121.880685,10.123,20.133,30.123,10.5,88.1,99.2,-2,1,44,7,11,22,33,-3,23\n</code>

'''Manifest:'''
<pre>
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.INTERNET" />
</pre>

'''Dependencies:'''
<pre>
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'com.google.android.gms:play-services-maps:17.0.0'
compile 'com.google.maps.android:android-maps-utils:0.4+'
implementation 'androidx.cardview:cardview:1.0.0'
implementation 'com.google.android.gms:play-services-location:17.0.0'
implementation 'androidx.appcompat:appcompat:1.1.0'
implementation 'androidx.constraintlayout:constraintlayout:1.1.3'
implementation 'com.android.support:design:28.0.0'
implementation 'androidx.navigation:navigation-fragment:2.2.1'
implementation 'androidx.navigation:navigation-ui:2.2.1'
implementation 'androidx.lifecycle:lifecycle-extensions:2.2.0'
</pre>

[[File:CMPE243_S20_T2_BLUETOOTHFLOWCHART.png|thumb|center|650px| Android Application Flowchart]]

=== Technical Challenges ===
*'''Bluetooth Discovery:''' While creating the android application, we were not able to see any Bluetooth devices in the paired device list. The problem was that for the Android versions above Lillipop we would also need location access. We have solved it by writing a function to check whether to check for permissions or not.
<pre>
private void checkBluetoothPermissions() {
Log.d(TAG, "checkBTPermissions: Checking permissions");
int permission_check = this.checkSelfPermission("Manifest.permission.ACCESS_FINE_LOCATION");
permission_check += this.checkSelfPermission("Manifest.permission.ACCESS_COARSE_LOCATION");
if (permission_check != 0) {
this.requestPermissions(new String[]{Manifest.permission.ACCESS_FINE_LOCATION, Manifest.permission.ACCESS_COARSE_LOCATION}, 1001); //Any number
}
else{
Log.d(TAG, "checkBTPermissions: No need to check permissions. SDK version < LOLLIPOP.");
}
}
</pre>
*'''Catching NULL in a StringTokenizer: ''' When sending data using Bluetooth sometimes thee app crashes. Using debug Run log in Android Studio IDE, we have found out that this is because we get <code> NullPointerException, java.util.StringTokenizer </code> error. This is mainly due to passing a null value to the StringTokenizer constructor. This problem can be avoided by after reading a line from the Bluetooth StringBuffer, we check whether it is null, before passing it to the StringTokenizer, but later on, we have preferred to use <code>split();</code> to prase the received string as StringTokenizer is now a legacy class that is retained for compatibility reasons and its use is discouraged in new code.

*'''XML Layouts: ''' Generating layouts is difficult for new android code developers, the design layouts made should be compatible for a wide range of mobile devices but using the new android libraries we have found that, the older phones then tend to have difficulty in showing the layouts correctly. We have solved this problem by learning the design commercial XML design layouts by following tutorials on Udemy and Youtube.

*'''Auto Connect''': During the first stages we have implemented Bluetooth connection via searching for all devices and clicking on the device from Listpair to connect. This has a lot of time to process all the discovered devices near range. To solve this we have hardcoded the HC-05 device address <code>00:14:03:06:02:83</code> to <code>mBluetoothAdapter.getRemoteDevice("device address")</code>.

 

== '''Management''' ==
===Git Management===

Git Management amongst 6 team members was definitely a very challenging task. Depending on our initial design we could’ve had a lot of merge conflicts. However those risks were mitigated by spending a LOT of time in the initial stages to decide our pipeline and structure.

<li>There are certain components in our system that were COMMON. For example the CAN initialization, communication and decodes were all similar for the most part between all the 4 Controllers. The utility modules used were also similar in nature</li>
<li>Thus we made a common branch that contained the templates for CAN Nodes (not Controllers), Hardware code and Utility functions.
<ol>
<li>Later this common branch was forked into an individual Controller specific branch (SENSOR, GEO, MOTOR or DRIVER).</li>
<li>Only the Logic folder contained Controller specific code, specific to that controller.</li>
</ol>
<li>This gave us a lot of flexibility since all the team members had similar APIs to work with on all 4 branches. This promoted easy understanding and learning.
<ol>
<li>Many team members frequently worked on 2 or more controllers at a time where can messages were concerned. Having a APIs also meant that just the can_handler needed to be updated regularly followed by the equivalent logic code. </li>
<li>Inside the logic folder, getters to the can node modules were frequently used.</li></ol>

An example of how one of our initial templates was setup.
<pre>
├───can_module
│ ├───can_bus_initializer
│ ├───can_constants
│ ├───can_driver_node
│ ├───can_geo_node
│ ├───can_handler
│ ├───can_motor_node
│ ├───can_sensor_node
│ └───test
├───hardware
│ ├───bt
│ ├───compass
│ ├───gps
│ ├───lcd
│ ├───lidar
│ ├───motor
│ ├───test
│ └───ultrasonic
├───logic
│ ├───driver_obstacle
│ ├───driver_state
│ ├───geo_logic
│ └───test
└───utility
├───line_buffer
└───test
</pre>

'''Challenges'''
<li>It was initially a bit of a learning curve to understand the flow of the repository</li>
<li>When using a git management system with different versions in each branch it became very tough when the number of branches suddenly exploded in size. A lot of relevant code was stuck in a lot of different branches.
<ol>
<li>This happened mainly due to assignment submissions and unclosed MRs that eventually became stale.</li>
<li>Our strategy was to abandon these MRs and keep forking from these branches without merging it back into its final controller branch.</li>
<li>The latest branches that were kept were aptly named `<controller>_bleeding_edge_dev` branches since they were never merged back from where they were forked.</li>
</ol>
<li>Since a lot of our code also depended on the DBC autogenerated code, we could not suddenly change the DBC Message names once they were established since it caused a change in the Struct name that was generated and used.
<ol>
<li>Our solution to this was to keep everything backward compatible. We added new function names without deleting old DBC messages.</li>
<li>In certain places where we wanted to modify a function name it was done one by one so that a lot of the code is not broken at one time.</li>
</ol>
<li>Common Branches eventually became stale as our progress continued on the bleeding edge branches
<ol>
<li>For example certain GPS features needed to be added which were done on the GEO_bleeding_edge_dev branch but never pushed or cherry-picked back into the COMMON branch.</li>
<li>This was a similar issue to our 2nd point but manageable since the goal of the COMMON branch was to provide a template for further work and nothing more.</li>
<li>At the end of the day each controller is its own Individual Project and while the messages between them are same. The Hardware code does not need to be same.</li>
<li>This also prompted team-members to ask if we could delete unused hardware or logic file code (which wasn’t being used and was imported from the template). This was also fine and can be done during cleanup stage. However we eventually got used to the Modular system of our project so much so that we did not worry about the additional modules that were present in each branched controller project.</li>
</ol>

 

== '''Conclusion''' ==
CMPE243 gives one of the best experiences one could ever get in their academic life. The course is designed to give an insight into how the industry functions and enhances both technical and management skills. Apart from learning how to work and implement application of CAN protocol, one can get a hands-on experience with version control, unit-testing and software design. Overall it was a very great and memorable journey.

=== Project Video ===

[https://youtu.be/zkTs8o7nB6k | Youtube Video]

=== Project Source Code ===
* [https://gitlab.com/coder137/can-ster_truck GitLab Link]

=== Advise for Future Students ===
'''GENERAL:'''
* Form your team and start the project as early as you can.
* Clearly discuss what role each individual should do and ensure that progress is regularly tracked so that the team doesn't fall back on any schedule.
* Make sure your early structure of the project is decided. Before you start to write the code make sure that all the team and code guidelines are discussed. In our case we spent most of our first week deciding how we wanted to structure and design our code. This paid off in the long run since we had robust code inside one repository that could be extended efficiently.
* Make sure each module is individually testable i.e through periodic callbacks as well as unit-tests. While unit-tests can help for a lot of situations and provide a robust way to map the working of the module, it cannot simulate certain real-life scenarios. For example, Lidar buffer was constantly getting full due to the large number of incoming bytes. This caused us to have certain incorrect reading appear after a few minutes of the lidar running. Our solution was to minimize the <code>printf</code> statements inside the module that were used for debugging.
* Since lot of code and hardware integration is involved with this project, make sure testing is thoroughly and periodically done and make note of all the issues found.
'''HARDWARE:'''
* Decide on how you would power up the peripherals. We had issues with Bluetooth (not connecting), GPS (lock not happening) and LIDAR (giving incorrect values). After lot of cycles of hardware and software debugging, we found that the issue was with power. Choose wisely as to which peripherals must be connected to which power source.
* Isolate the power hungry devices to other parallel connections so that the voltage drop is not high. In our case the Graphical LCD and LIDAR were both very power hungry peripherals. The LCD used to start glitching incase there was a large voltage drop and the LIDAR used to give incorrect values or not update correctly. We solved this issue by giving the lidar a dedicated power supply.
* PCB design involves lot of hardware components. Coordinating with multiple team members and verifying each hardware connection takes quite some time. So start well ahead.
* Make sure to expose some extra GPIO and GND pins for future use.
'''MOTOR:'''
* You can use the LiPo battery to power the RPM and servo motor instead of using a separate power source. Use Vout from the ESC to get 6V.
* Start the PID control calibration early on as you will need to do extensive testing to get it working.

=== Acknowledgement ===
<HR>
Firstly we would like to express our gratitude to Professor Preetpal Kang for his guidance throughout the semester and providing us with this opportunity. We would also like to thank the ISA members Vignesh Kumar Venkateshwar and Aakash Vrajlal Chitroda for being available whenever in need and guiding us to complete the project.

== '''References''' ==
* CAN Reference [https://www.kvaser.com/about-can/can-dictionary/]
* FreeRTOS Reference [http://socialledge.com/sjsu/index.php/FreeRTOS_Tutorial]
* Git tutorial [http://socialledge.com/sjsu/index.php/Basic_Git_Tutorial]
* Unit-test reference [https://gitlab.com/sibros_public/public/-/wikis/c/unit_tests#lab-1]
* Getting started with SJ-Two [https://sjsu-dev2.readthedocs.io/en/latest/getting_started/getting_started/]

===Motor Controller===
* Traxxas User Manual: [https://images-na.ssl-images-amazon.com/images/I/D1NTpa7RNES.pdf]
* Traxxas Specification Sheet: [https://images-na.ssl-images-amazon.com/images/I/81WphBAuwIL.pdf]

===Geological Controller===
* Movable Scripts (Calculate distance, bearing and more between Latitude/Longitude points): [https://www.movable-type.co.uk/scripts/latlong.html]
* CMPS11 (I2C Configuration): [https://www.robot-electronics.co.uk/htm/cmps11i2c.htm]

===Bridge and Sensor Controller===
* [https://www.slamtec.com/en/Lidar/A1 LIDAR]
* [https://components101.com/ultrasonic-sensor-working-pinout-datasheet Ultrasonic sensor ]
===Driver and LCD Controller===
* LCD Software: [https://4dsystems.com.au/ulcd-32ptu 4Dsystems]
===Android===
* Youtube Channel: [https://www.youtube.com/channel/UCoNZZLhPuuRteu02rh7bzsw Coding with Mitch]
* Android Developers: [https://developer.android.com/guide/topics/connectivity/bluetooth Website][https://github.com/googlearchive/android-BluetoothChat Github]
* Udemy Course: [https://www.udemy.com/course/the-complete-android-oreo-developer-course/ Complete Android Oreo Developer Course]
===PCB Design===
* Design Tool: [https://easyeda.com/ EasyEDA]

S20: Canster Truck

2020-05-23T06:51:12Z

Proj user22: /* Project Video */

[[File:CMPE243_S20_T2_Canster_Truck_Logo.png|thumb|455px|caption|right|CAN-STER TRUCK LOGO]]

== '''Abstract''' ==
The Canster Truck Project is an autonomous RC car with CAN Bus interfaced controllers. The development of the RC car's subsystem modules (Interfacing of Ultrasonic Sensor, LIDAR, Bluetooth, GPS, Compass and CAN modules) was divided among six team members. The aim of the project is to develop an autonomous RC Car which can navigate from one source location to the selected destination on the app by avoiding obstacles in its path using sensors. Waypoints algorithm is used as the path finding technique.
 

== '''Introduction and Objectives''' ==

'''The project was divided into 7 modules:'''

* '''Bridge and Sensor Controller'''
* '''Motor Controller'''
* '''Geological Controller'''
* '''Driver and LCD Controller'''
* '''Hardware Integration'''
* '''Android Application'''
* '''Testing & Code Review'''

'''RC Car Objectives'''
'''1. Driver and LCD Controller''' - Handles algorithms for obstacle avoidance, route maneuvering, and waypoints
'''2. Geological Controller''' - Recieves coordinates from GPS and Heading from Compass for navigation
'''3. Motor Controller''' - Controls movements of the RC Car
'''4. Bridge and Sensor Controller''' - Detects surrounding objects and interfaces android application to controller via bluetooth
'''Team Objectives'''

[[File:CMPE243_S20_T2_High_Level_System_Diagram.png|thumb|center|800px| High Level System Diagram]]

 

== '''Team Members and Responsibilities''' ==
[[File:CMPE243_S20_T2_Canster Truck_Team.jpg|thumb|center|800px| Group Picture]]

'''Gitlab Project Link''' - [https://gitlab.com/coder137/can-ster_truck '''Canster Truck''']
 

*'''Niket Naidu''' [https://www.linkedin.com/in/niket-naidu-30090a134/ LinkedIn] [https://gitlab.com/coder137 Gitlab]
** '''Geological Controller''' : GPS, Compass, Waypoint Algorithm, Haversine and Bearing Angle logic
** '''Driver and LCD Controller''' : GLCD
** '''Bridge and Sensor Controller''' : Bluetooth
** '''Testing & Code Review'''

*'''Ganesh Ram Pamadi''' [https://www.linkedin.com/in/ganeshram93/ LinkedIn] [https://gitlab.com/ganeshram2493 Gitlab]
** '''Hardware Integration'''
** '''Testing & Code Review'''
** '''Driver Controller'''
** '''Motor Controller'''

*'''Nikhil Pabbisetty''' [https://www.linkedin.com/in/nikhilpabbisetty/ LinkedIn] [https://gitlab.com/nikhilpeoria Gitlab]
** '''Bridge and Sensor Controller'''
** '''Motor Controller'''
** '''Driver and LCD Controller'''
** '''Hardware Integration'''

*'''Akhil Cherukuri''' [https://www.linkedin.com/in/akhilcherukuri/ LinkedIn] [https://gitlab.com/akhilcherukuri Gitlab] [https://github.com/akhilcherukuri Github]
** '''Android Application'''
** '''Bridge and Sensor Controller'''

*'''Ashish Anant Ladage''' [https://www.linkedin.com/in/ashish-anant-ladage-7bb3a214b/ LinkedIn] [https://gitlab.com/ashishladage1 Gitlab]
** '''Driver and LCD Controller'''
** '''Hardware Integration'''
** '''Motor Controller'''

*'''Jesus De Haro De Reza''' [https://www.linkedin.com/in/jesus-de-haro-66342424/ LinkedIn] [https://gitlab.com/deharo27 Gitlab]
** '''Bridge and Sensor Controller'''
** '''Motor Controller'''

 

== '''Administrative Responsibilities''' ==
* '''Team Lead''' - [https://www.linkedin.com/in/niket-naidu-30090a134/ '''Niket Naidu''']
* '''Git Repository Manager''' - [https://www.linkedin.com/in/niket-naidu-30090a134/ '''Niket Naidu''']
* '''Bill Of Materials Manager''' - [https://www.linkedin.com/in/akhilcherukuri '''Akhil Cherukuri''']
* '''Wiki Report Manager''' - [https://www.linkedin.com/in/akhilcherukuri '''Akhil Cherukuri''']

 

== '''Schedule''' ==

{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-

! scope="row"| '''1'''
| style="text-align:center;" |'''02/11/2020'''
| style="text-align:center;" |'''02/17/2020'''
|
*'''Form teams and decide group name'''
*'''Review past projects'''
*'''Slack: Create project group and invite Preet'''
*'''GitLab: Create project groups repository'''
*'''Analysis of component required'''

|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''2'''
| style="text-align:center;" |'''02/18/2020'''
| style="text-align:center;" |'''02/24/2020'''
|
*'''Study CAN Communication'''
*'''Create Bill of Materials'''
*'''Order RC Car'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''3'''
| style="text-align:center;" |'''02/25/2020'''
| style="text-align:center;" |'''03/02/2020'''
|
*'''Setup team finance management using Splitwise application'''
*'''Complete Bill of Materials'''
*'''Order all other required components'''
*'''Wikipedia: Setup project report template'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''4'''
| style="text-align:center;" |'''03/03/2020'''
| style="text-align:center;" |'''03/09/2020'''
|
*'''Read the respective datasheets and manuals for each component'''
*'''Test each component for working conditions'''
|
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''5'''
| style="text-align:center;" |'''03/10/2020'''
| style="text-align:center;" |'''03/16/2020'''
|
*'''Assign team responsibilities and roles'''
*'''Setup team project management environment (ClickUp)'''
*'''Define CAN DBC'''
*'''Research GPS antennas and order'''
*'''Android: Environmental setup of Android Studio and enable version control'''
*'''Hardware : Decide PCB editing software (easyEDA)'''
*'''Hardware : Draft schematic for required PCB design'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''6'''
| style="text-align:center;" |'''03/17/2020'''
| style="text-align:center;" |'''03/23/2020'''
|
*'''Hardware : Create model of PCB''' 
*'''Android: Add a Button for changing bluetooth connection status in the application''' 
*'''Geological: Interface Compass module with SJ-2 board using I2C interface''' 
*'''Geological: Interface GPS module with SJ-2 board using the UART interface''' 
*'''Geological: Parse raw data to get meaningful values for GPS and Compass''' 
*'''Sensor: Interface and check the functionality of ultrasonic sensors to the SJ-2 board''' 
*'''Motor: Interface of Servo & DC motor to the SJ-2 board and check for basic functionality''' 
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''7'''
| style="text-align:center;" |'''03/24/2020'''
| style="text-align:center;" |'''03/30/2020'''
|
*'''Hardware : Finalize components placement on PCB.''' 
*'''Motor: Add PWM functionality and test the code on DC and servo motors''' 
*'''Sensor: Interface and check and study the output readings of Lidar sensor with SJ-2 board over UART''' 
*'''LCD Display: Explore UI designing of LCD''' 
*'''Hardware: Finalize on optimal ultrasonic sensor placements''' 
*'''Android: Initiate Bluetooth communication and show staus via text view''' 
*'''Wikipedia: Establish final wiki schedule'''
*'''Complete CAN communication format for each controller and link DBC file to the Wiki'''
*'''Complete high-level system block diagram'''
*'''Complete unit-level block diagrams'''
*'''Bridge: Interface HC-5 bluetooth module with Sj-2 board using serial communicaton'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''8'''
| style="text-align:center;" |'''03/31/2020'''
| style="text-align:center;" |'''04/06/2020'''
|
*'''Hardware: Analyze PCB model and order PCB Circuit board''' 
*'''Android: Initiate Bluetooth communication and send "Hello World".''' 
*'''Wikipedia: Start adding information/images/diagrams to the relevant sections'''
*'''Motor: Configure ESC for correct speed outcome according to frequency & PWM values''' 
*'''Motor: Finish RPM sensor hardware and software implementation and integration''' 
*'''Sensor: Read output from Lidar and setup structure for outputting for DBC''' 
*'''Geological: Implement waypoints algorithm''' 
*'''Driver: Implement obstacle avoidance algorithm''' 
*'''Bridge: Pass data such as "Hello World" from HC-05 bluetooth module to bluetooth terminal android application'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''9'''
| style="text-align:center;" |'''04/07/2020'''
| style="text-align:center;" |'''04/13/2020'''
|
*'''Hardware: Remove Unused parts from RC Car''' 
*'''Hardware: Mount PCB and 3D Parts''' 
*'''Motor: Decide different cut-off values from sensor to command right /slight right/ straight/ slight left/ left to motor.''' 
*'''Android: Embed Google Maps API for setting the car's destination.''' 
*'''LCD: Work to show RC cars live status information(battery level, current speed, long, lat, bearing, sensor data, etc)''' 
*'''Driver: Test obstacle avoidance algorithm and fine-tune sensor readings''' 
*'''Geological: Test checkpoint algorithm''' 
*'''Bridge: Establish two way communication between android application and bluetooth module''' 
*'''Update Bill of Materials for miscellaneous hardware'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''10'''
| style="text-align:center;" |'''04/14/2020'''
| style="text-align:center;" |'''04/20/2020'''
|
*'''Hardware: Integrate all hardware modules''' 
*'''LCD: Testing & Validation of the LCD UI and display vehicle status information''' 
*'''Android: Send car location to the app and checkpoints received to Geo module''' 
*'''Motor: Optimize PID control by accelerating/decelerating as instructed by Driver''' 
*'''Bridge: Configure HC-05 for auto reconnection if bluetooth communication disconnects''' 
*'''Add multiple debug messages and transmit on CAN'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''11'''
| style="text-align:center;" |'''04/21/2020'''
| style="text-align:center;" |'''04/27/2020'''
|
*'''Android: Send additional vehicle status information from RC car to the Application for display''' 
*'''Android: Finalize User Interface Design and Icon''' 
*'''Continuously test the whole system and handling of corner cases (outside).'''
*'''Finalize RC Car For Project Proto 1'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''12'''
| style="text-align:center;" |'''04/28/2020'''
| style="text-align:center;" |'''05/04/2020'''
|
*'''Gitlab: Push final code'''
*April 28th: Project Proto 1
*'''Finalize RC Car for Project Demo'''
*May 1st: Project Presentation
*'''Finalize RC Car for Project Proto 2'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''13'''
| style="text-align:center;" |'''05/05/2020'''
| style="text-align:center;" |'''05/21/2020'''
|
* '''Complete Individual Contribution Peer Grading'''
* '''Review and Complete Wiki Project Page'''
|
*'''Completed'''
*'''Completed'''
|-
|}

 

== '''Bill Of Materials''' ==
{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Item#
! scope="col"| Part Description
! scope="col"| Part Model & Vendor
! scope="col"| Quantity
! scope="col"| Cost in USD
|-
! scope="row"| 1
| '''Microcontroller Boards'''
| SJ2 Boards (Purchased from Preet Kang)
| 4
| $200.00
|-
! scope="row"| 2
| '''CAN Transceivers'''
| [https://www.waveshare.com/sn65hvd230-can-board.htm Waveshare SN65HVD230]
| 12
| $54.48
|-
! scope="row"| 3
| '''RC Car'''
| [https://www.amazon.com/Traxxas-Slash-Course-2-4GHZ-Vehicle/dp/B01DU474B0/ref=sr_1_3?ie=UTF8&qid=1474747759&sr=8-3&keywords=Traxxas+1%2F10+slash+2wd Traxxas 2WD RTR with 2.4Ghz Radio]
| 1
| $260.00
|-
! scope="row"| 4
| '''Lithium-Ion Battery'''
| [https://www.rcsuperstore.com/traxxas-7600mah-2s-7-4v-25c-id-lipo-battery-pack/ Traxxas 7600mAh 2S 7.4V 25C iD LiPo Battery Pack]
| 1
| $75.00
|-
! scope="row"| 5
| '''Lithium-Ion Battery Charger'''
| [https://www.amazon.com/Traxxas-2970-EZ-Peak-Charger-Identification/dp/B00OAFYLJC/ref=pd_bxgy_21_img_2?ie=UTF8&psc=1&refRID=JVX791WVV9Y8T9DW92KW Traxxas 2970 EZ-Peak Plus 4-Amp NiMH/LiPo Fast Charger]
| 1
| $50.00
|-
! scope="row"| 6
| '''Compass Breakout Board'''
| [https://www.dfrobot.com/product-1275.html DFRobot CMPS11 Compass]
| 1
| $29.99
|-
! scope="row"| 7
| '''Bluetooth Breakout Board'''
| [https://www.amazon.com/HC-05-Bluetooth-Pass-through-Wireless-Communication/dp/B01G9KSAF6/ref=sr_1_4?ie=UTF8&qid=1507077325&sr=8-4&keywords=arduino+bluetooth+hc-05 DSD TECH Bluetooth HC-05]
| 1
| $8.49
|-
! scope="row"| 8
| '''LIDAR Sensor'''
| [https://www.amazon.com/RPLiDAR-A1M8-Degree-Laser-Scanner/dp/B07H7X3SFF/ref=sr_1_fkmrnull_1?crid=2FSUI76G4UA8K&keywords=rplidar+a1m8+-+360+degree+laser+scanner+development+kit&qid=1552764172&s=gateway&sprefix=RPlidar%2Caps%2C263&sr=8-1-fkmrnull SEEED STUDIO RPLIDAR A1M8]
| 1
| $109.99
|-
! scope="row"| 9
| '''RPM Sensor'''
| [https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM Traxxas 6520 RPM Sensor]
| 1
| $13.70
|-
! scope="row"| 10
| '''GPS Breakout Board'''
| [https://www.adafruit.com/product/746 Adafruit Ultimate GPS Breakout v3]
| 1
| $44.30
|-
! scope="row"| 11
| '''LCD Display'''
| [https://4dsystems.com.au/ulcd-32ptu 4Dsystems 3.2 TFT-LCD ULCD-32PTU]
| 1
| $79.00
|-
! scope="row"| 12
| '''Ultrasonic Sensors'''
| [https://www.amazon.com/gp/product/B01COSN7O6/ ELEGOO HC-SR04 Ultrasonic Module]
| 5
| $12.00
|-
! scope="row"| 13
| '''GPS Antenna'''
| [https://www.amazon.com/dp/B07RRT615K/ GPS Antenna A1-UX]
| 1
| $10.98
|-
! scope="row"| 14
| '''PCB Fabrication'''
| [https://jlcpcb.com/ JLCPCB]
| 5
| $40.15
|-
! scope="row"| 15
| '''Miscellaneous'''
| [https://www.amazon.com Amazon],[https://www.mouser.com/ Mouser Electronics],[https://www.digikey.com/ Digikey],[https://anchor-electronics.com/ Anchor Electronics]
| ~
| $48.07
|-
! scope="row"|
|
|
| '''Total'''
| '''$1036.15'''
|-

|}

 

== '''Printed Circuit Board''' ==

=== Design And Architecture ===
The complete PCB (for boards and hardware peripherals) was designed using EasyEDA online software. The 4 nodes will be communicating via CAN bus and other peripherals are connected to the PCB via headers.

=== Power Section===
We have 2 power banks supplying our system. And the Servo Motor, RPM sensor and DC rear Motor (via ESC) are powered using LiPo battery (6 volts).
* Power bank #1 - Subset 2

* Power bank #2 - Subset 1, Subset 3, Bluetooth Module

'''NOTE:'''

'''Subset 1:'''
1. LIDAR
2. LCD
3. Compass

'''Subset 2:'''
1. Motor node
2. Driver node
3. BS node

'''Subset 3:'''
1. Geo node
2. Back ultrasonic sensor

=== Fabrication ===
* PCB was sent to fabrication to JLCPCB China which provided PCB with MOQ of 5 and 2 layers of PCB and common grounded the rest of the copper area.
'''DRC elements (in mils)'''
* Track Width = 12
* Clearance = 10
* Via Diameter = 24
* Via Drill Diameter = 12

=== Challenges ===
* Auto-routing gave lot of challenges (only ~60% success) and sometimes the online server even crashes and faces downtime. Even local routing had lot of issues. So make sure to plan your design accordingly.
* We started our PCB design well ahead of the project. So lot of pre-planning had to be done with regard to final hardware and placement of components in order to avoid spending extra time and money while re-ordering.
* The PCB went through a lot of internal revisions even before placing order. This was time-consuming.

'''Other hardware challenges:'''
* Figuring out why various hardware peripherals (GPS, Bluetooth, LIDAR and Ultrasonic sensor) started to malfunction (devices were on but values were either inconsistent / not occurring), took a lot of time to debug. It was due to insufficient power.

 
[[File:CMPE243 S20 T2 EasyEDA.png|1040x1200px|thumb|center|PCB Layout Design in EasyEDA]]
 
[[File:CMPE243 S20 T2 PCB SCHEMATIC.jpg|1041x550px|thumb|center|PCB Schematic]]
 
[[File:CMPE243 S20 T2 PCBFRONT.jpg|thumb|center|600px|PCB Top Layer]]
 
[[File:CMPE243 S20 T2 PCBBACK.jpg|thumb|center|600px|PCB Bottom Layer]]

 

== '''CAN Communication''' ==

=== Hardware Design ===
[[File:CMPE243_S20_T2_Canster_Truck_CANHW.png|thumb|center|770px| CAN Hardware Diagram]]

=== DBC File ===

DBC FILE: [https://gitlab.com/coder137/can-ster_truck/-/blob/dbc-improvements/projects/lpc40xx_freertos/project.dbc Gitlab]

<pre>
VERSION ""

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

BS_:

BU_: DBG DRIVER IO MOTOR SENSOR GEO

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" GEO,MOTOR,SENSOR

BO_ 101 GEO_HEARTBEAT: 1 GEO
SG_ GEO_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,MOTOR,SENSOR

BO_ 102 MOTOR_HEARTBEAT: 1 MOTOR
SG_ MOTOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,SENSOR

BO_ 103 SENSOR_HEARTBEAT: 1 SENSOR
SG_ SENSOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,MOTOR

BO_ 200 MOTOR_STEERING: 1 DRIVER
SG_ MOTOR_STEERING_direction: 0|8@1- (1,0) [-2|2] "" MOTOR

BO_ 210 DRIVER_COORDINATES: 8 DRIVER
SG_ DRIVER_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
SG_ DRIVER_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 220 MOTOR_SPEED: 1 DRIVER
SG_ MOTOR_SPEED_processed: 0|8@1- (1,0) [-3|3] "" MOTOR

BO_ 300 GEO_DEGREE: 8 GEO
SG_ GEO_DEGREE_current: 0|32@1+ (0.000001,0) [0|360] "degrees" DRIVER
SG_ GEO_DEGREE_required: 32|32@1+ (0.000001,0) [0|360] "degrees" DRIVER

BO_ 310 GEO_DESTINATION_REACHED: 1 GEO
SG_ GEO_DESTINATION_REACHED_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 400 MOTOR_SPEED_FEEDBACK: 4 MOTOR
SG_ MOTOR_SPEED_current: 0|32@1+ (0.1,0) [0|60] "kph" DRIVER

BO_ 500 SENSOR_BT_COORDINATES: 8 SENSOR
SG_ SENSOR_BT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
SG_ SENSOR_BT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 510 SENSOR_SONARS: 8 SENSOR
SG_ SENSOR_SONARS_left: 0|21@1+ (0.001,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right: 21|21@1+ (0.001,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle: 42|21@1+ (0.001,0) [0|0] "cm" DRIVER

BO_ 520 SENSOR_LIDAR: 8 SENSOR
SG_ SENSOR_LIDAR_middle: 0|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_slight_left: 16|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_slight_right: 32|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_back: 48|16@1+ (1,0) [0|0] "cm" DRIVER

BO_ 530 MOTOR_KEY: 1 SENSOR
SG_ MOTOR_KEY_val: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 900 GEO_CURRENT_COORDINATES: 8 GEO
SG_ GEO_CURRENT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" DBG
SG_ GEO_CURRENT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" DBG

BO_ 901 GEO_DISTANCE_FROM_DESTINATION: 4 GEO
SG_ GEO_distance_from_destination: 0|32@1+ (0.001,0) [0|0] "meters" DBG

BO_ 902 MOTOR_INFO_DBG: 4 MOTOR
SG_ MOTOR_INFO_DBG_rps: 0|16@1+ (1,0) [0|0] "" DBG
SG_ MOTOR_INFO_DBG_pwm: 16|16@1+ (0.001,0) [0|0] "" DBG

BO_ 903 LIPO_BATTERY_VOLTAGE_DBG: 4 MOTOR
SG_ LIPO_BATTERY_VOLTAGE_val: 0|32@1+ (0.01,0) [0|0] "volts" DBG

BO_ 904 CURRENT_CHECKPOINT_DBG: 1 GEO
SG_ CURRENT_CHECKPOINT_val: 0|8@1+ (1,0) [0|0] "" DBG

CM_ "--BU (Network Node) Information--";
CM_ BU_ DRIVER "The driver controller of the car";
CM_ BU_ GEO "The geo controller of the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";

CM_ "--BO (Message) Information--";
CM_ BO_ 100 "Driver Sync message used to synchronize the controllers";
CM_ BO_ 101 "Geo Sync message used to synchronize the controllers";
CM_ BO_ 102 "Motor Sync message used to synchronize the controllers";
CM_ BO_ 103 "Sensor Sync message used to synchronize the controllers";

CM_ BO_ 200 "Steering direction values sent by Driver Node to Motor Node";
CM_ BO_ 210 "Driver Destination coordinates sent by Driver Node";
CM_ BO_ 220 "Required motor speed computed from Driver Node to Motor Node";

CM_ BO_ 300 "Current and computer/required degree values sent by Geo Node";
CM_ BO_ 310 "Indicator signal to check if the RC car has reached the destination";

CM_ BO_ 400 "Current motor info (rps and kph) sent as feedback to the Driver Node";

CM_ BO_ 500 "Coordinate BT values (destination coordinates) sent by Sensor Node";
CM_ BO_ 510 "LIDAR - Distance from obstacle detected in each sector";
CM_ BO_ 520 "Ultrasonic Sensor - Distance from obstacle detected by each sensor";
CM_ BO_ 530 "Start/Stop signal from the Bluetooth app";

CM_ BO_ 900 "Destination coordinates for BUSMASTER debugging";
CM_ BO_ 901 "Distance from destination";
CM_ BO_ 902 "Supplied PWM value to the motor and its RPM";
CM_ BO_ 903 "LIPO Battery Voltage";
CM_ BO_ 904 "Current checkpoint of the car";

CM_ "--SG (Signal) Information for Heartbeats--";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver node";
CM_ SG_ 101 GEO_HEARTBEAT_cmd "Heartbeat command from the geological node";
CM_ SG_ 102 MOTOR_HEARTBEAT_cmd "Heartbeat command from the motor node";
CM_ SG_ 103 SENSOR_HEARTBEAT_cmd "Heartbeat command from the sensor node";

CM_ "--SG (Signal) Information for DRIVER Node--";
CM_ SG_ 200 DRIVER_STEERING_direction "Calculated Driver Steering values (-2,2) for Motor";
CM_ SG_ 210 DRIVER_COORDINATES_latitude "Destination Latitude coordinate";
CM_ SG_ 210 DRIVER_COORDINATES_longitude "Destination Longitude coordinate";
CM_ SG_ 220 MOTOR_SPEED "Calculated Driver speed values (-3,3) for Motor";

CM_ "--SG (Signal) Information for GEO Node--";
CM_ SG_ 300 GEO_DEGREE_current "Current Geo Degree relative to true north";
CM_ SG_ 300 GEO_DEGREE_required "Calculated Geo Degree computed by Haversine Formula";
CM_ SG_ 310 GEO_DESTINATION_REACHED "Indicator signal to check if the RC car has reached the destination";

CM_ "--SG (Signal) Information for MOTOR Node--";
CM_ SG_ 400 MOTOR_SPEED_FEEDBACK "Feedback speed (kph) sent by Motor Node";

CM_ "--SG (Signal) Information for SENSOR Node--";
CM_ SG_ 500 SENSOR_BT_COORDINATES_latitude "Destination Latitude received over Bluetooth";
CM_ SG_ 500 SENSOR_BT_COORDINATES_longitude "Destination Longitude received over Bluetooth";
CM_ SG_ 510 SENSOR_SONARS_left "Ultrasonic Sensor attached to the left side";
CM_ SG_ 510 SENSOR_SONARS_right "Ultrasonic Sensor attached to the right side";
CM_ SG_ 510 SENSOR_SONARS_middle "Ultrasonic Sensor attached to the middle";
CM_ SG_ 510 SENSOR_SONARS_back_left "Ultrasonic Sensor attached to the back left side";
CM_ SG_ 510 SENSOR_SONARS_back_right "Ultrasonic Sensor attached to the back right side";
CM_ SG_ 520 SENSOR_LIDAR_middle "Lidar sensing the middle sector (-15 to 15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_left "Lidar sensing the slight left sector (-45 to -15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_right "Lidar sensing the slight right sector (15 to 45 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_back "Lidar sensing the back of the car (165 to 195 degrees)";
CM_ SG_ 530 MOTOR_KEY_val "1 -> Start the motor from the app, 0 -> Stop";

CM_ SG_ 900 GEO_CURRENT_COORDINATES_latitude "Current Latitude";
CM_ SG_ 900 GEO_CURRENT_COORDINATES_longitude "Current Longitude";
CM_ SG_ 901 GEO_distance_from_destination "Distance from destination";
CM_ SG_ 902 MOTOR_INFO_DBG_rps "Current RPS value of the motor";
CM_ SG_ 902 MOTOR_INFO_DBG_pwm "Supplied motor PWM value";
CM_ SG_ 903 LIPO_BATTERY_VOLTAGE_val "LIPO Battery Voltage";
CM_ SG_ 904 CURRENT_CHECKPOINT_val "Current checkpoint of the car";

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

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

BA_ "GenMsgCycleTime" BO_ 100 1000;
BA_ "GenMsgCycleTime" BO_ 200 50;
BA_ "FieldType" SG_ 100 DRIVER_HEARTBEAT_cmd "DRIVER_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 102 GEO_HEARTBEAT_cmd "GEO_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 103 MOTOR_HEARTBEAT_cmd "MOTOR_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 104 SENSOR_HEARTBEAT_cmd "SENSOR_HEARTBEAT_cmd";

BA_ "FieldType" SG_ 200 MOTOR_STEERING "MOTOR_STEERING";
BA_ "FieldType" SG_ 230 MOTOR_SPEED_val "MOTOR_SPEED_val";
BA_ "FieldType" SG_ 310 GEO_DESTINATION_REACHED_cmd "GEO_DESTINATION_REACHED_cmd";

VAL_ 100 DRIVER_HEARTBEAT_cmd 2 "DRIVER_HEARTBEAT_cmd_REBOOT" 1 "DRIVER_HEARTBEAT_cmd_SYNC" 0 "DRIVER_HEARTBEAT_cmd_NOOP" ;
VAL_ 101 GEO_HEARTBEAT_cmd 2 "GEO_HEARTBEAT_cmd_REBOOT" 1 "GEO_HEARTBEAT_cmd_SYNC" 0 "GEO_HEARTBEAT_cmd_NOOP";
VAL_ 102 MOTOR_HEARTBEAT_cmd 20 "MOTOR_HEARTBEAT_cmd_REBOOT" 10 "MOTOR_HEARTBEAT_cmd_SYNC" 0 "MOTOR_HEARTBEAT_cmd_NOOP" ;
VAL_ 103 SENSOR_HEARTBEAT_cmd 200 "SENSOR_HEARTBEAT_cmd_REBOOT" 100 "SENSOR_HEARTBEAT_cmd_SYNC" 0 "SENSOR_HEARTBEAT_cmd_NOOP" ;

VAL_ 200 MOTOR_STEERING_direction -2 "MOTOR_STEERING_hard_left" -1 "MOTOR_STEERING_slight_left" 0 "MOTOR_STEERING_straight" 1 "MOTOR_STEERING_slight_right" 2 "MOTOR_STEERING_hard_right";
VAL_ 220 MOTOR_SPEED_processed -3 "MOTOR_SPEED_reverse_fast" -2 "MOTOR_SPEED_reverse_medium" -1 "MOTOR_SPEED_reverse_slow" 0 "MOTOR_SPEED_neutral" 1 "MOTOR_SPEED_forward_slow" 2 "MOTOR_SPEED_forward_medium" 3 "MOTOR_SPEED_forward_fast";
VAL_ 310 GEO_DESTINATION_REACHED_cmd 1 "GEO_DESTINATION_REACHED_cmd_REACHED" 0 "GEO_DESTINATION_REACHED_cmd_NOT_REACHED";
</pre>

 

== '''Motor Controller''' ==
'''[https://gitlab.com/coder137/can-ster_truck/-/tree/motor_bleeding_edge_dev GitLab Link]'''

This controller is used to control the components of the car-related to motor. We can control the speed and steering of the car having interfaced with various components with the SJ-2 board. The servo motor is controlled via PWM and is used to set the steering direction of the car. The DC motor is controlled by the Electronic Speed Controller (ESC) via PWM for speed. We read the speed of the car by using an RPM sensor. By using the RPM sensor values, a feedback loop has been designed to regulate the speed of the car. A state machine has been designed to manage the forward and backward movements of the car.
Additionally, a voltage divider circuit has been implemented to read the battery voltage. All motor functionality and CAN message communication is run at 10 Hz.

=== Hardware Design ===

[[File:CMPE243_S20_T2_Canster_Truck_Motor_Hardware.png|thumb|center|750px| Motor Hardware System]]

The following diagram details the hardware implementation of the motor module with the SJTwo board:
Hardware Interface
=====Servo Motor=====
The servo motor responds to PWM pulses. It has three pins namely Vcc, PWM Input Signal, and GND. The servo is powered using 6V from the car battery. Based on the PWM signal supplied from the SJTwo board the front wheels are turned.
[[File:CMPE243_S20_T2_Canster_Truck_Motor_1.jpg|440px|thumb|center|| Servo Motor]]
{| class="wikitable" style="text-align: center; width: 400px; height: 200px; margin: left;"
|+ Servo Motor Pin Connection
|-
! Sr. No.
! Wires - Servo Motor
! Function
|-
! 1
| PWM Connected to P2.5 || PWM Signal from Sj-2 Board
|-
! 2
| VCC || 6V supply from ESC
|-
! 3
| GND || Common Ground
|-
|}

=====Electronic Speed Controller (ESC)=====
The ESC is used to control the DC motor. It is supplied power using the 7.4 V LiPo battery. It has three pins namely Vout, PWM Input Signal, and GND. Based on the PWM input signal, the speed and forward, neutral, and backward movements of the car is changed. Vout is given to the RPM sensor and Servo motor.
[[File:CMPE243_S20_T2_Canster_Truck_Motor_2.jpg|440px|thumb|center|| Electronic Speed Controller (ESC)]]
{| class="wikitable" style="text-align: center; width: 400px; height: 200px; margin: left;"
|+ Speed Sensor Pin Connection
|-
! Sr. No.
! Wires - RPM Sensor
! Function
|-
! 1
| Signal Wire Connected to P2.0 || GPIO that supplies pulses to controller
|-
! 2
| VCC || 6V supply from ESC
|-
! 3
| GND || Common Ground
|-
|}

=====DC Motor=====
The DC motor is controlled using the ESC. It has two pins, a positive and a negative terminal. A PWM signal wire is connected to the microcontroller and the required current is provided by the LiPo battery and the ESC. The DC motor is controlled using PWM at 10Hz.

[[File:CMPE243_S20_T2_Canster_Truck_Motor_3.jpg|320px|thumb|center|| DC Motor]]
{|
|-
|
{| class="wikitable" style="text-align: center; width: 400px; height: 200px; margin-left:0px;"
|+ DC Motor Pin Connection
|-
! Sr. No.
! Wires - DC Motor
! Description
|-
! 1
| Positive Wire (already connected) || Positive Terminal
|-
! 2
| Negative Wire (already connected || Negative Terminal
|-
|}
 
{| class="wikitable" style="text-align: center; width: 400px; height: 200px;"
|+ DC Motor Configuration
|-
! Operation
! Pulse Width Range (ms)
! Duty Cycle(%)
|-
! FORWARD
| 1.51 - 2.00 || 15.1-20.0
|-
! STOP
| 1.50 || 15.0
|-
! REVERSE
| 1.00 - 1.49 || 10.0-14.9
|-
|}
|
|-
|}

Note: First calibrate the DC motor or the motor will not respond to your PWM pulses. For help with calibration go to this [https://traxxas.com/support/Programming-Your-Traxxas-Electronic-Speed-Control website]

=====RPM Sensor=====

The RPM sensor is used to get the current speed of the car. We use the info for creating a feedback loop (PID) for maintaining the speed of the car in uphill and downhill situations. The RPM sensor mounts on the rear DC motor shaft compartment with a special assembly also provided by Traxxas. The magnet which attached to the inner gear generates a pulse each rotation. The sensor works on the hall effect principle where it provides a current across its terminal when placed in a magnet's field. The RPM sensor has three pins namely Vcc, Signal, and GND.

[[File:CMPE243_S20_T2_Canster_Truck_Motor_4.jpg|440px|thumb|center|| RPM Sensor]]

{| class="wikitable" style="text-align: center; width: 400px; height: 200px; margin: left;"
|+ Speed Sensor Pin Connection
|-
! Sr. No.
! Wires - RPM Sensor
! Function
|-
! 1
| Signal Wire Connected to P2.2 || GPIO that supplies pulses to controller
|-
! 2
| VCC || 6V supply from ESC
|-
! 3
| GND || Common Ground
|-
|}

=== Software Design ===

The software for the motor node was divided into multiple files and made modular to improve readability and understanding of the complex logic involved. The main code modules are for:
*Servo Motor
*Electronic Speed Controller
*RPM Sensor
*Motor Wrapper
*Battery Voltage

The motor wrapper module is used to wrap all the code from the esc, servo, and rpm modules into simple to use functions to be called in the periodic tasks.
=====Servo Motor=====
It uses the steering value sent from the driver (-2 to 2) and matches it to the appropriate PWM value for steering. This code module is run at 10Hz.
<pre>
void servo__steer_processor(int16_t steering_value) {
switch (steering_value) {
case MOTOR_STEERING_hard_left:
servo__steer_hard_left();
break;
case MOTOR_STEERING_slight_left:
servo__steer_soft_left();
break;
case MOTOR_STEERING_straight:
servo__steer_straight();
break;
case MOTOR_STEERING_slight_right:
servo__steer_soft_right();
break;
case MOTOR_STEERING_hard_right:
servo__steer_hard_right();
break;
default:
printf("\nDid not receive steering value");
}
}
</pre>
=====Electronic Speed Controller=====

This code module is used to control the DC motor. It receives the motor direction value from the driver and sets the appropriate PWM value. Based on the value the motor is commanded to move the car forward or backwards. A switch case is implemented to set PWM values for movement in different directions along with different speeds.
<pre>
void esc__direction_processor(int16_t direction_value) {
desired_direction_value = direction_value;
switch (direction_value) {
case MOTOR_SPEED_reverse_fast:
esc__reverse_fast();
break;
case MOTOR_SPEED_reverse_medium:
esc__reverse_medium();
break;
case MOTOR_SPEED_reverse_slow:
esc__reverse_slow();
break;
case MOTOR_SPEED_neutral:
esc__neutral();
break;
case MOTOR_SPEED_forward_slow:
esc__forward_slow();
break;
case MOTOR_SPEED_forward_medium:
esc__forward_medium();
break;
case MOTOR_SPEED_forward_fast:
esc__forward_fast();
break;

default:
printf("\nDid not receive direction and speed value");
}
}
</pre>

There is also a feedback loop to control the speed. The ESC code depends on the rpm sensor code for the current speed values.
<pre>
double current_speed = get_speed_kph();
double desired_speed = desired_speed_kph;
float adjusted_duty_cycle = 0.0;
adjusted_duty_cycle = duty_cycle + (speed_to_pwm_adjustment(desired_speed, current_speed));
</pre>

[[File:CMPE243_S20_T2_Canster_Truck_Motor1.png|thumb|center|500px| Feedback Loop for Motor Speed]]

=====RPM Sensor=====
This code module is used to get current speed data from the RPM sensor. It is based on interrupts. When the wheel rotates once, we get one pulse due to the magnet installed. This pulse generates a falling edge interrupt during which we increment the pulse counter. Since, this code is run at 1Hz we collect the number of pulses generated every one second. This gives us the number of rotations per second using which we can calculate the speed in kph.
<pre>
float rpm__calculate_speed_kph() {
uint16_t rotation_per_sec = pulse_count;
pulse_count = 0;
speed_kph = ((CIRCUMFERENCE_METER * rotation_per_sec) * (MPS_TO_KPH_CONVERSION_FACTOR)) / GEAR_RATIO;
return speed_kph;
}
</pre>

=====Motor Wrapper=====
As mentioned above, the main function of this code module is to wrap all the other code modules and call the right functions at the appropriate frequency. The motor wrapper code also includes a state machine for ensuring a smooth transition between forward to backward state and vice versa. In order to achieve a smooth transition, a series of PWM pulses must be generated at the right time. For example, when the motor is moving from forward to backward state, a reverse value must be given first followed by at least three neutral values, and then continue with reverse values.

[[File:CMPE243_S20_T2_Canster_Truck_Motor2.png|thumb|center|500px| State Machine Flowchart for Motor Movements]]

=====LiPo Battery Voltage=====

The LiPo Battery Voltage was calculated using ADC in Burst Mode. A LiPo Hardware module was created for the same which contained two functions, <code>lipo__init</code> and <code>lipo__get_voltage</code>.

The voltage divider circuit is stepped down from 7.4V to 2.1V using 10K and 4K Resistor pair.
[[File:CMPE243_S20_T2_Canster Truck_Motor_Voltage_Regulator.png|thumb|center|400px| Voltage Regulator]]
'''LiPo Initialization'''

The LiPo Initialization phase initializes the ADC, Enables Burst mode on the ADC pins and configures the Alternate Function Registers for the same.

'''Getting LiPo Voltage'''

We read the raw ADC value from the LPC Hardware register. This value will be from 0 - 3.3V. However due to our voltage divider configuration the max voltage that we should theoretically get is 2.1V. This means that 2.1V corresponds to 7.4V of the LIPO Battery voltage.

The formula used is
<code>(raw_adc_value * MAX_LIPO_BATTERY_VOLTAGE_VALUE) / MAX_LIPO_ADC_VALUE</code>

=== Technical Challenges ===
<li>Changing movements of the car from Forward to Backward and vice versa
If you just change the PWM value from say 16 (Forward) to 14(Backward), the DC motor will just stop and will not make wheels turn reverse. We discovered this problem quite late as during the initial testing we had always run the car from the start with either forward or reverse but never tried changing the direction during run-time.
 
Solution: The motor requires a series of PWM pulses which is specific to the car to transition from forward mode to reverse mode. In our case we had to give the PWM pulses in the following sequence. Suppose,
<ol>
<li> Forward (16) (callback_count = 0)</li>
<li> Forward (16) (callback_count = 1)</li>
<li> Reverse (14) (callback_count = 2)</li>
<li> Neutral (15) (callback_count = 3)</li>
<li> Neutral (15) (callback_count = 4)</li>
<li> Neutral (15) (callback_count = 5)</li>
<li> Reverse (14) (callback_count = 6)</li>
<li> Continue reverse</li>
</ol>
Similarly, the reverse to forward can also be implemented.
<li>DC motor shooting off when there is an improper ground connection
When we connected the battery voltage circuit for reading the voltage from the battery, the motor would randomly shoot off every now and then.
 
Solution: Connect the voltage divider circuit to the common ground rather than taking the ground from the ESC.</li>

 

== '''Geological Controller''' ==
'''[https://gitlab.com/coder137/can-ster_truck/-/tree/geo_bleeding_edge_dev_waypoints GitLab Link]'''

===Messages===
*GEO_HEARTBEAT: Used to check for MIA by other nodes. Highest priority message for GEO Node

*GEO_DEGREE: Sends the current degree relative to the North Pole computed by the Compass and the Required degree relative to the North Pole computed by Bearing Angle using the Current Coordinate and Destination Coordinate.

*GEO_DESTINATION_REACHED: Sets a flag, 0 for destination not reached and 1 for destination reached

*GEO_CURRENT_COORDINATES: Debug Message used to send the Current GPS Coordinates

*GEO_DISTANCE_FROM_DESTINATION: Debug message used to send the Distance from Destination

*CURRENT_CHECKPOINT_DBG: Debug message used to check which checkpoint is being navigated to

=== Hardware Design ===

[[File:CMPE243_S20_T2_GEO1.png|thumb|center|650px| Geological Diagram]]

=== Software Design ===
=====Overview=====
*Inside the `periodic_callback__initialize`
**Initialize the CAN BUS
**Initialize the GPS

*Inside the `periodic_callback__1hz`
**Handle all MIA (from other Nodes)
**Update GPS LED when init and in case of failure
**Compute the GEO logic for Waypoints algorithm once every second (1000 ms)

*Inside the `periodic_callback__10hz`
**Handle CAN Incoming messages (Decode)
**Transmit CAN Geo messages (Encode and send)
**Compute the GPS Coordinate

=====Compass I2C Driver=====
An online datasheet resource was used to work with the Compass ([https://www.robot-electronics.co.uk/htm/cmps11i2c.htm CMPS11 Datasheet])
Initially the Compass I2C Driver was tested using the Terminal I2C Helper built by our Professor Preetpal Kang. Using this resource we were quickly able to read various I2C Registers and display it onto the terminal.

For our project the only required part of the Compass was the 16-bit Compass Bearing value (0-3599) i.e 0-359.9 degree values. These values were stored in the 2nd and 3rd register (Register 2 being the High Byte).
Once the raw data was received over I2C we could easily combine the data

<pre>
uint16_t bearing_value = (Reg2 << 8) | Reg3;
float rval = bearing_value / 10.0;
return rval;
</pre>
The returned value were transmitted to the Driver Node to compute its steering based on the required Bearing Angle.

=====GPS Initialization=====
GPS Initialization activates the Hardware GPIO (RX and TX), FreeRTOS Queue for UART Interrupts (UART Module) and Line Buffer Module to parse each GPS line.

=====GPS Data Parsing=====
The GPS Hardware module transmits an NMEA string over UART to the SJTwo Board. We read each character one by one and add it to the Line Buffer module.
Inside its computation loop, the Line Buffer module checks if a newline character has been received.
When a newline character has been received the entire string is extracted from the line buffer module and parsed according to its identifier ($GPRMC, $GPGGA) received and parsed into individual tokens.
For our purposes the $GPRMC NMEA string was the most appropriate and it helped us extract the Current Latitude Longitude as well as the Valid/Invalid tag for the Canster Truck.

=====GPS LED Indication for debugging=====

A simple module that checks for the GPRMC GPS Message and extracts the A or V valid (Tag). If $GPRMC NMEA string is valid, LED is set, else LED is reset. This gives us onsite debugging capabilities to know if GPS has locked onto a satellite signal.

=====GEO Logic Module Computation=====
The GEO Logic Module computes the Bearing Angle, Haversine Distance as well as the Waypoints algorithm.

'''Bearing Angle:'''

<code>
θ = atan2( sin Δλ ⋅ cos φ2 , cos φ1 ⋅ sin φ2 − sin φ1 ⋅ cos φ2 ⋅ cos Δλ )
</code>

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

Since atan2 returns values in the range -π ... +π (that is, -180° ... +180°), to normalize the result to a compass bearing (in the range 0° ... 360°, with −ve values transformed into the range 180° ... 360°), convert to degrees and then use (θ+360) % 360, where % is (floating point) modulo.
For final bearing, simply take the initial bearing from the endpoint to the start point and reverse it (using θ = (θ+180) % 360).

The above article reference gives us the required bearing angle that our car must align itself to, to reach a particular destination coordinate from its current coordinate.
The Steering of the vehicle depends on the above-computed angle values.

'''Haversine Distance Formula:'''

This uses the ‘haversine’ formula to calculate the great-circle distance between two points – that is, the shortest distance over the earth’s surface – giving an ‘as-the-crow-flies’ distance between the points (ignoring any hills they fly over, of course!).

<code>
a = sin²(Δφ/2) + cos φ1 ⋅ cos φ2 ⋅ sin²(Δλ/2)

c = 2 ⋅ atan2( √a, √(1−a) )

d = R ⋅ c
</code>

where φ is latitude, λ is longitude, R is earth’s radius (mean radius = 6,371km);
note that angles need to be in radians to pass to trig functions!

The above formula is used to calculate the distance between the source coordinate (received via GPS) and the destination coordinate.
Later this was used to compute the distance between source coordinate and each individual checkpoint to traverse the shortest distance.

'''Waypoints Algorithm:'''

The Waypoints algorithm that was chosen was a slightly modified version of Djikstra’s Algorithm.
3 values were calculated before the final computation

* Distance between source and final destination (DISTsd)
* Distance between source and each individual checkpoint (DISTsc)
* Distance between each individual checkpoint and the final destination. (DISTcd)

If '''DISTsd''' was lesser than '''DISTcd''', this checkpoint was discarded (we continue in the loop). Since we would be moving in the opposite direction, rather than towards the final destination.

If '''DISTsd''' was greater than '''DISTcd''', then we checked the nearest checkpoint to the source.
The minimum value was set initial that was equal to '''DISTsd'''.

If '''DISTsc''' was lesser than the minimum value stored, '''DISTsc''' would become the new minimum value, and the checkpoint index and coordinates would be appropriately stored and returned from the function.

In this way we would navigate to the nearest checkpoint from the source, while also making sure NOT to travel in the opposite direction.
This logic is recomputed only when we reach the checkpoint selected and the algorithm runs again to find the next checkpoint that we need to navigate to.

=====CAN Decode Destination Coordinates=====
Destination Coordinates are received from the Bridge and Sensor Node and transmitted over the CAN Bus. The value is decoded and stored in the GEO Logic Module.
This is a very important value since our entire GEO Logic calculations are based on the Destination Coordinate.

=====CAN Encode and Send=====

The main messages that were transmitter are
#Geo Degree
#Geo Destination Reached
#Distance from Destination Debug and Checkpoint Index debug

'''Geo Degree Computation as per Waypoints Algorithm:'''

Geo Degree was computed as per the current coordinates and the most recently computed checkpoint coordinates. This bearing angle calculation w.r.t computed checkpoint would continue till we do not reach that particular checkpoint.
Once we reach the computed checkpoint, Waypoint algorithm is recomputed as per the process mentioned above and the algorithm runs again.

'''Geo Destination Reached:'''

An Area of around 4 meters was set around the destination coordinate to check if the destination had been reached.
This measurement was taken into consideration to allow for the loss in precision when transmitting data over CAN as well as any irregularities that might occur when getting values from the GPS.
Having an area of 4 meters was very accurate for all of our test runs.

'''Geo Distance from Destination Debug and Checkpoint Index Debug:'''

Getting debug information was very critical to speed up our development process. In this case we could actively see if our algorithm worked properly.
The Geo Distance from Destination was used to see if we were moving closer to our destination or veering further away from it.
The Checkpoint Index was used to see which checkpoint index we were traveling to. By knowing the placements of the Individual checkpoints we could manually as well as programmatically (via Android application) verify the working of our Canster Truck.

=== Technical Challenges ===
#DBC Challenge for GEO Coordinates -> Could not encode more than 5-6 decimal places at a time, on later investigation we found that the 10000 is an int value, however 100000 overflows the int value.
#Creating an efficient algorithm for Waypoints, O(n) complexity.
#Getting appropriate fixes for GPS when not in a completely open space.
#GPS used to fluctuate or stop giving values when Battery voltage went below a particular threshold. Always supply 3.3V constantly at a good amperage.

 

== '''Sensor [Bridge and Sensor Controller]''' ==
'''[https://gitlab.com/coder137/can-ster_truck/-/tree/sensor_bleeding_edge_dev GitLab]'''
==='''Ultrasonic Sensor'''===
====Hardware Design====
This sensor uses an ultrasonic beam to measure the distances. Based on the time taken between when the beam is sent and received back to the sensor, the distance is calculated in the node.
Apart from 5v and GND, this sensor has 2 pins ECHO and TRIG which are interfaced with the SJ-Two board via GPIO.

[[File:CMPE243_S20_T2_CansterTruck_ultrasonic_sensor.jpg|thumb|center|300px| Ultrasonic Sensor Diagram]]

====Software Design====
* Init the GPIO pin connected to TRIG of the sensor as output and for ECHO as an input port.
* Attach the interrupt on the ECHO input port.
* Store the system_clock_count before setting the trigger pulse and then set the pulse. Also keep monitoring the input port.
* Take the system_clock_count at the instant of receiving the interrupt.
Distance = (system_clock_count_at_trig - system_clock_count_after_at_echo) / 57.14

==='''Lidar Sensor'''===
====Hardware Design====
The RPLidar sensor can be powered from a 5v source and uses UART communication to receive commands and transmit data. It has seven pins to interface with. Two sets of the pins (four total) are for power and ground. The remaining three are for UART receive and transmit, and for making the lidar’s motor spin.

[[File:CMPE243_S20_T2_Canster_Truck_RPLidar_A1.JPG|thumb|center|300px| RPLidar A1]]

====Software Design====
In terms of the lidar, the SJ2 initializes GPIO, UART, and memory for storing the measurement values. After initialization, the command to begin scanning is sent. Here, we wait for the lidar to send a response packet, letting the host (SJ2 board) know it received the command. The response packet the lidar sends will be 7 bytes. If the correct 7 bytes are not received, the command will be sent again.

[[File:CMPE243_S20_T2_Canster Truck_Lidar_flow.jpeg|thumb|center|200px| Lidar Flow]]

Following the response packet, the lidar begins sending 5-byte measurement data. Each sample contains a distance measurement (in millimeters) and the angle (with respect to the lidar) in which it was taken. The data packet structure is shown in the following figure. In addition to containing the distance and angle, the packet includes a quality value, to indicate the reliability of the measurement, and three check bits (S, ~S, and C). As the data is received via UART, we wait until we have 5 bytes before continuing to process. Before processing the 5 bytes after receiving them, the check bits are confirmed to be correct. If they are incorrect, it will not be processed and we will wait for another sample to be received.

[[File:CMPE243_S20_T2_Canster Truck_DataPacketStructure.JPG|thumb|center|200px| Data Packet Structure]]

In the case the sample is correct, each measurement value that is in a direction of interest will be placed in an array designated to one of four directions (left, right, front, rear). Each of these directions have their own sector in the lidar’s 360-degree view.
*Right sector: 11° - 30°
*Rear sector: 170° - 190°
*Left sector: 330° - 349°
*Front sector: 350° - 370° (or 10°)

The arrays mentioned will hold roughly 20 measurements, which are every degree in the sector. In the event, objects are too far to measure, the lidar will report 0 mm. distance. Since there is no measurable obstacle, a “large” distance value of 3000 mm. is placed in the array. The smallest distance value will be taken from each array and reported to the driver node for obstacle avoidance.

=== Technical Challenges ===
====Ultrasonic Sensor====
*'''Power issue''' The pulses were getting triggered incorrectly and it took a while to figure out that it was due to insufficient power.

====LIDAR====
*'''Datasheet not 100% clear:''' The correct datasheet for the was a bit difficult to obtain, and the manufacturer needed to be contacted. The first document found online was high level and general information about the sensor, but the manufacturer did provide another document that contained the information of the commands and responses to and from the lidar, and their packet structure. The documents did not clearly state the angles with respect to the lidar are fixed, which left me wondering if the lidar will think the direction it is facing when powered on will become the new “zeroth” angle.

*'''UART Buffer Overflow:''' When first interfacing with the sensor, the incoming bytes of the lidar were printed on to the terminal to make sure there was a response and to make sense of the information. Since the command we sent results in 5 bytes of data per measurement samples from the lidar and the lidar measured 2000 times per second, there are will be roughly 10k Bytes per second of data incoming that need to be handled continuously. With an improperly sized UART buffer and print statements it is guaranteed to occur, making the lidar data look like random values.

*'''Proper Parsing of Measurement Data:''' After sending a command to the lidar, the sensor will send a response packet, followed by the measurement data. The initial response from the lidar is a 7-byte packet, followed by continuous 5-byte measurement samples. I needed to make sure however I handled the response would be independent of how the measurement is handled, so as not to create a potential unwanted offset when receiving measurements.

*'''Object Detection with Received Data:''' Once proper communication was set up with the lidar and measurement data was getting decoded, there needed to be a way to measure when obstacles were present. If ~360 measurements are handled entirely independently from one another, it could become a complex and confusing code. To achieve a simple approach, four sectors about 20 degrees in size were used to represent the front, left, right, and rear directions.

*'''Bugs in Code:''' When first implementing the code, there were a few bugs from typos, incorrect numbers, and some faulty logic that were found with the use of unit testing. Unit testing helped find these issues and verified the logic was correct, and I would say gave me 90% confidence in my lidar handling.

 

== '''Bluetooth Module [Bridge and Sensor Controller]'''==

Bridge functionality of the Bridge and Sensor Controller is to establish wireless communication between the SJ-2 Board and the android mobile device using the HC-05 Bluetooth module. The Bridge controller will be receiving start command with destination GEO coordinates and stop command. The Bridge controller will be transmitting the required sensor data and debug information to be displayed on the android application.

[[File:CMPE243_S20_T2_BRIDGE.png|thumb|center|500px| Bridge Diagram]]

==== Software Design ====

'''Low-Level Layer'''

In this layer, similar to the GPS the UART GPIO was initialized (RX, TX), FreeRTOS Queue was initialized for UART Interrupts and the line buffer module was initialized to parse strings.

Two basic functions <code>bt__read</code> and <code>bt__write</code> were implemented.
As the name suggested, <code>bt__write</code> took a string as its input parameter and transmitted that data to the Android application. <code>bt__read</code> stored the incoming characters into the line buffer, parsed the line received into its identifier and tokens, and invoked a callback function.

Since this was a low-level layer the User would not be directly invoking this library. Instead a '''Bluetooth Wrapper''' module was created which would be invoked and used by the user.

'''Application Layer'''

The Bluetooth Wrapper module had the appropriate <code>read_once</code> and <code>write_once</code> functions.

The <code>read_once</code> function internally just called the <code>bt__read</code> function. All of the decodings was done inside the Callback Function.
To get the Destination coordinate the string received from the Android Application was in the form of
<code>$loc,<destination_latitude>,<destination_longitude>.</code>
Upon receiving this data we parsed the destination_latitude and destination_longitude, which could later be accessed using getters.
We also set a start flag to notify the Driver Node that destination has been received and we can start steering towards our checkpoints.

Another command implemented was the stop command.
<code>$stop</code>
This was used to send a stop flag to the Driver node.

The <code>write_once</code> function used the getter methods from each CAN Decode message and update its internal state variables. A CSV String was created using the <code>$canster</code> identifier and various debugging points were appended to this message using a comma.
On the Android application side this CSV string was tokenized and displayed onto the Application Debug screen appropriately.

==== Technical Challenges ====

'''Bluetooth peripheral not turning on'''
* We initially connected the Bluetooth module directly to the SJ-Two board with (Vcc = 3.3v). But it was not giving only 2.7v and hence the device did not turn on.
* We had to connect it to external power source to make it function without hassles.

 

== '''Driver [Driver and LCD Controller]''' ==
'''[https://gitlab.com/coder137/can-ster_truck/-/tree/driver_bleeding_edge_dev GitLab]'''

=== Software Design ===

[[File:CMPE243_S20_T2_Canster Truck_Driver_Flowchart.png|thumb|center|750px|Driver Flowchart]]

The above block diagram explains the process flow of obstacle detection for the car. The LIDAR detects
the obstacle and depending on the distance of obstacle the car takes a slight right and slight left or a
hard right and hard left. The state of the car also depends on the value of the LIDAR and ultrasonic sensor.
The loose ends of the LIDAR for the reverse condition are checked by the ultrasonic sensors. The
The ultrasonic sensor works on the principle of trigger and echo and can detect the obstacles very close by.
The range of the Ultrasonic sensor is lower than the LIDAR. Finally, if no obstacle is detected the car goes
straight until the destination is reached. The speed of the car is also various when an obstacle is detected to
avoid the crash and the car’s smooth transition from one state to another. The key to the android
application controls the start and stop the process of the car. If the key is not pressed, then the stays in the

neutral state. The speed of the car is controlled by the changing duty cycle of the input voltage. There
are seven-speed levels in which the motor can run on. These speed levels are Forward Slow, Medium,
Fast, Reverse Slow, Medium, Fast, and Neutral. The Neutral is the stop condition with a 0% duty cycle.

=== Technical Challenges ===

Technical Challenges faced during obstacle detection:

*Due to dimensions of the car and for the perfect obstacle avoidance the values of 100cm and 150cm had to be selected for the turning radius. Hence, it is very important to calibrate these values appropriately, as these values will be unique for different car designs.
*For a situation, where even if the lidar doesn’t detect any obstacle at the middle, the car must take a slight right or a slight left as per our design. This is the case where the obstacle can be a moving one and that is why the lidar middle couldn’t detect it.

 

== '''LCD [Driver and LCD Controller]''' ==
=== Hardware Design ===
[[File:CMPE243_S20_T2_Canster_Truck_LCD_Diagram.png|thumb|600px|center| LCD Design]]
{|style="text-align: center; width: 400px; height: 200px; margin: auto;"
|
[[File:CMPE243_S20_T2_Canster_Truck_GLCD.jpg|thumb|200px|center| GLCD Hardware]]
||
[[File:CMPE243_S20_T2_Canster_Truck_GLCD2.jpg|thumb|600px|center| GLCD Software Simulation (Initial Iteration)]]
|
|}

=== Software Design ===
The GLCD used was created by 4DSystems, using their IDE a UI was created. Each UI component could be controlled by sending UART data targeted at the widget address.
The best part about this GLCD was that we had a lot of interactive widgets to display debugging information in real-time.
The GLCD code was divided into 3 parts:

=====Low-Level Initialization=====
Initialize the low-level hardware interfaces to send and receive data from the GLCD.
Similar to the GPS and Bluetooth, The UART GPIO was initialized (RX, TX), FreeRTOS Queue was initialized for UART Interrupt and line buffer was used to get a stream of data for parsing.

Low-level '''read''' and '''write''' commands were used as per the working of the GLCD Module.
When Reading data pertaining to a widget on the GLCD we would need to send a particular response packet.

<pre>
void lcd__read(lcd_object_e object_id, uint8_t object_index, uint8_t *response, uint16_t *response_data) {

uint8_t checksum = READ_OBJ ^ object_id ^ object_index;
uint8_t buffer[] = {READ_OBJ, object_id, object_index, checksum};

lcd__write_data(buffer, sizeof(buffer) / sizeof(uint8_t));
lcd__read_response_id(response);
lcd__read_response_data(response_data);
}
</pre>

The response_data returned contains the Widget ID as well as the current value stored on that widget.

When Writing data pertaining to a widget on a GLCD the process is similar to the above mentioned code.
<pre>
void lcd__write(lcd_object_e object_id, uint8_t object_index, uint8_t msb, uint8_t lsb, uint8_t *response) {
uint8_t checksum = WRITE_OBJ ^ object_id ^ object_index ^ msb ^ lsb;
uint8_t buffer[] = {WRITE_OBJ, object_id, object_index, msb, lsb, checksum};

lcd__write_data(buffer, sizeof(buffer) / sizeof(uint8_t));
lcd__read_response_id(response);
}
</pre>

However in this case we receive only an ACK or NACK from the system. ACK would mean that the write to GLCD widget was successful and the widget now stored appropriate values. NACK would mean that a particular error has occurred. The errors could be regarding baud rate, incorrect bit format, incorrect index values, etc.

=====GLCD Wrapper for Widgets=====
The above low-level code had generic read and write functions. However for our UI we were only using 3 Widgets. All of which had '''different Indexes''' and '''Widget IDs'''.
Therefore a very simple library was created to easily interface with those widgets
<pre>
bool lcd_wrapper__read_led(uint8_t index);
uint16_t lcd_wrapper__read_meter(uint8_t index);
uint16_t lcd_wrapper__read_leddigit(uint8_t index);

bool lcd_wrapper__write_led(uint8_t index, bool value);
bool lcd_wrapper__write_meter(uint8_t index, uint16_t value);
bool lcd_wrapper__write_leddigit(uint8_t index, uint16_t value);
</pre>

The above code is self-explanatory read and write functions for '''LED''', '''METER''', and '''LED DIGIT'''.

=====GLCD UI=====
Now that we had our low level and Widget wrapper working properly, we wanted to create our Dynamic UI as well. The code would need to be robust enough to handle any UI that we create on the GLCD which could be reflected equivalently in our C Code.

<pre>
static void lcd_ui__update_ui(void) {

lcd_wrapper__write_led(LCD_LED_DRIVER_MIA_INDEX, driver_mia_led);
lcd_wrapper__write_led(LCD_LED_SENSOR_MIA_INDEX, sensor_mia_led);
lcd_wrapper__write_led(LCD_LED_GEO_MIA_INDEX, geo_mia_led);
lcd_wrapper__write_led(LCD_LED_MOTOR_MIA_INDEX, motor_mia_led);

// kph is always in the range of 0 - 10
lcd_wrapper__write_meter(LCD_METER_KPH_INDEX, kph_meter % 11);

// These will be in the Range of 0-99
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_RPM_INDEX, rpm_leddigit % 100);
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_CURRENTDEGREE_INDEX, cdegree_leddigit % 100);
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_REQUIREDDEGREE_INDEX, rdegree_leddigit % 100);
}
</pre>

As we can see the <code>lcd_ui__update_ui</code> function was called periodically inside the 1Hz function. It updated the screen in real time based on the static values that were stored AND updated inside the LCD UI module.
The Constant INDEX values stored were directly mapped onto the Index values were received from the 4DWorkshop UI Software.

=== Technical Challenges ===

*The GLCD needs to be supplied appropriate voltage (5V) at 1A for it to work properly. The LCD does not turn on without an appropriate power supply
*The GLCD UART interface has an additional RES signal. This RES signal resets the GLCD when pulled low. When connecting the UART display it is recommended to always reset the GLCD display for proper working
*The GLCD has a latency of up to 30ms when querying and receiving data. In our case, the real-time system has hard caps on time (i.e up to 1second of delay is possible on the 1Hz function)
*This was rectified by putting the read functions (if any) inside the low priority 1Hz periodic_callback function.
*Write operations do not suffer from such a latency issue since they only send one byte (ACK or NACK) signal back.
*Fortunately most of our logic involved just a write (setting a value on the GLCD) rather than reading or querying the widget.

 

== '''Android Application''' ==
[https://gitlab.com/akhilcherukuri/can-ster_truck_application Gitlab]
=== Software Design ===

<div><ul>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android4.jpg|thumb|none|220px|Info Activity (Top)]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android7.jpg|thumb|none|220px|Info Activity (Middle)]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android5.jpg|thumb|none|220px|Info Activity (Bottom)]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android6.jpg |thumb|none|220px|Debug Activity Screen]]</li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster_Truck_Android_GIF1.gif|thumb|center|220px|App Animations]]</li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster_Truck_Android_GIF2.gif|thumb|center|220px|Live Location]]</li>
</ul></div>
The application consists of a total of 5 Activities:

=====Main Activity=====
**This is the app launch display screen
**It will check for all the required permission onStart().
**Has search button for connecting from a paired device list view
**Once device is clicked, an intent will start the Map Activity
=====Map Activity=====
* For this requirement we are using the Google Maps Fragment, for the map fragment to function we must request an API key from Google and set the key in the manifest of the application.
* Destination marker(Red Marker) is set using <code>setOnMapClickListener</code> to which the car will navigate to, the destination can be changed by clicking elsewhere on the Map Fragment. The marker can be removed using <code>setOnMarkerClickListener</code>.
* When the start button is pressed, the start command identifier along with destination latitude and longitude is sent to the car via the write thread. A background thread is started along with it to indicate the current car's position(Green Marker) along with a plotline between the current position and destination.
* When the stop button is pressed, the stop command identifier is sent to the car, to stop and turn off the car.
=====Info Activity=====
* Messages from Geological, Driver, Motor coming from CAN bus are decoded by the Sensor and Bridge controller and sent to the Android application as a string.
* The received string is parsed and categorizes the data to store it in the required textView to be displayed.
* Bluetooth status, Lidar Values, Ultrasonic Sensor Values, Motor Speed, Motor RPM, Motor PWM, Cars' current location, Compass Heading, Distance till Destination, Checkpoint Index is displayed. This was useful for debugging purposes and allowed us to avoid scanning the mounted LCD or CAN Busmaster on PC during drives.
=====Debug Activity=====
*The main function of this activity is to check all RAW RX and RAW TX messages and create a log of all the data received and sent.
=====Bluetooth Connection Service Activity=====
*This is the background activity that handles all the threads required for transmission and receiving data using Bluetooth connections. It has 3 running threads which is called inside other activities using a handler:
* Accept Thread - Listens to BluetoothServerSocket using listenUsingRfcommWithServiceRecord. In order for the RF communication socket to connect to the HC-05, we used the following <code>UUID: 00001101-0000-1000-8000-00805F9B34FB</code>. This is a generic SSP Bluetooth UUID that enables the socket to directly connected to HC-05 and maintain the connection.
* Connect Thread - Creates a Bluetooth socket using createRfcommSocketToServiceRecord
* Connected Thread - Creates socket.getInputStream(); and socket.getOutputStream(); when bytes are available in input stream it will read them into a buffer.
**All messages for activities are done by <code> Handler mHandler.obtainMessage(); mHandler.sendMessage(); </code>

'''Receieved string:'''
* A String is sent to the Bluetooth app from HC-05 and when it receives a string with identifier "$canster", the message is prased accordingly by using the string delimiter ',' and is ended by the newline character '\n' which will remove the data from StringBuffer.
* <code>Example: $canster,37.339334,-121.881123,37.338713,-121.880685,10.123,20.133,30.123,10.5,88.1,99.2,-2,1,44,7,11,22,33,-3,23\n</code>

'''Manifest:'''
<pre>
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.INTERNET" />
</pre>

'''Dependencies:'''
<pre>
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'com.google.android.gms:play-services-maps:17.0.0'
compile 'com.google.maps.android:android-maps-utils:0.4+'
implementation 'androidx.cardview:cardview:1.0.0'
implementation 'com.google.android.gms:play-services-location:17.0.0'
implementation 'androidx.appcompat:appcompat:1.1.0'
implementation 'androidx.constraintlayout:constraintlayout:1.1.3'
implementation 'com.android.support:design:28.0.0'
implementation 'androidx.navigation:navigation-fragment:2.2.1'
implementation 'androidx.navigation:navigation-ui:2.2.1'
implementation 'androidx.lifecycle:lifecycle-extensions:2.2.0'
</pre>

[[File:CMPE243_S20_T2_BLUETOOTHFLOWCHART.png|thumb|center|650px| Android Application Flowchart]]

=== Technical Challenges ===
*'''Bluetooth Discovery:''' While creating the android application, we were not able to see any Bluetooth devices in the paired device list. The problem was that for the Android versions above Lillipop we would also need location access. We have solved it by writing a function to check whether to check for permissions or not.
<pre>
private void checkBluetoothPermissions() {
Log.d(TAG, "checkBTPermissions: Checking permissions");
int permission_check = this.checkSelfPermission("Manifest.permission.ACCESS_FINE_LOCATION");
permission_check += this.checkSelfPermission("Manifest.permission.ACCESS_COARSE_LOCATION");
if (permission_check != 0) {
this.requestPermissions(new String[]{Manifest.permission.ACCESS_FINE_LOCATION, Manifest.permission.ACCESS_COARSE_LOCATION}, 1001); //Any number
}
else{
Log.d(TAG, "checkBTPermissions: No need to check permissions. SDK version < LOLLIPOP.");
}
}
</pre>
*'''Catching NULL in a StringTokenizer: ''' When sending data using Bluetooth sometimes thee app crashes. Using debug Run log in Android Studio IDE, we have found out that this is because we get <code> NullPointerException, java.util.StringTokenizer </code> error. This is mainly due to passing a null value to the StringTokenizer constructor. This problem can be avoided by after reading a line from the Bluetooth StringBuffer, we check whether it is null, before passing it to the StringTokenizer, but later on, we have preferred to use <code>split();</code> to prase the received string as StringTokenizer is now a legacy class that is retained for compatibility reasons and its use is discouraged in new code.

*'''XML Layouts: ''' Generating layouts is difficult for new android code developers, the design layouts made should be compatible for a wide range of mobile devices but using the new android libraries we have found that, the older phones then tend to have difficulty in showing the layouts correctly. We have solved this problem by learning the design commercial XML design layouts by following tutorials on Udemy and Youtube.

*'''Auto Connect''': During the first stages we have implemented Bluetooth connection via searching for all devices and clicking on the device from Listpair to connect. This has a lot of time to process all the discovered devices near range. To solve this we have hardcoded the HC-05 device address <code>00:14:03:06:02:83</code> to <code>mBluetoothAdapter.getRemoteDevice("device address")</code>.

 

== '''Management''' ==
===Git Management===

Git Management amongst 6 team members was definitely a very challenging task. Depending on our initial design we could’ve had a lot of merge conflicts. However those risks were mitigated by spending a LOT of time in the initial stages to decide our pipeline and structure.

<li>There are certain components in our system that were COMMON. For example the CAN initialization, communication and decodes were all similar for the most part between all the 4 Controllers. The utility modules used were also similar in nature</li>
<li>Thus we made a common branch that contained the templates for CAN Nodes (not Controllers), Hardware code and Utility functions.
<ol>
<li>Later this common branch was forked into an individual Controller specific branch (SENSOR, GEO, MOTOR or DRIVER).</li>
<li>Only the Logic folder contained Controller specific code, specific to that controller.</li>
</ol>
<li>This gave us a lot of flexibility since all the team members had similar APIs to work with on all 4 branches. This promoted easy understanding and learning.
<ol>
<li>Many team members frequently worked on 2 or more controllers at a time where can messages were concerned. Having a APIs also meant that just the can_handler needed to be updated regularly followed by the equivalent logic code. </li>
<li>Inside the logic folder, getters to the can node modules were frequently used.</li></ol>

An example of how one of our initial templates was setup.
<pre>
├───can_module
│ ├───can_bus_initializer
│ ├───can_constants
│ ├───can_driver_node
│ ├───can_geo_node
│ ├───can_handler
│ ├───can_motor_node
│ ├───can_sensor_node
│ └───test
├───hardware
│ ├───bt
│ ├───compass
│ ├───gps
│ ├───lcd
│ ├───lidar
│ ├───motor
│ ├───test
│ └───ultrasonic
├───logic
│ ├───driver_obstacle
│ ├───driver_state
│ ├───geo_logic
│ └───test
└───utility
├───line_buffer
└───test
</pre>

'''Challenges'''
<li>It was initially a bit of a learning curve to understand the flow of the repository</li>
<li>When using a git management system with different versions in each branch it became very tough when the number of branches suddenly exploded in size. A lot of relevant code was stuck in a lot of different branches.
<ol>
<li>This happened mainly due to assignment submissions and unclosed MRs that eventually became stale.</li>
<li>Our strategy was to abandon these MRs and keep forking from these branches without merging it back into its final controller branch.</li>
<li>The latest branches that were kept were aptly named `<controller>_bleeding_edge_dev` branches since they were never merged back from where they were forked.</li>
</ol>
<li>Since a lot of our code also depended on the DBC autogenerated code, we could not suddenly change the DBC Message names once they were established since it caused a change in the Struct name that was generated and used.
<ol>
<li>Our solution to this was to keep everything backward compatible. We added new function names without deleting old DBC messages.</li>
<li>In certain places where we wanted to modify a function name it was done one by one so that a lot of the code is not broken at one time.</li>
</ol>
<li>Common Branches eventually became stale as our progress continued on the bleeding edge branches
<ol>
<li>For example certain GPS features needed to be added which were done on the GEO_bleeding_edge_dev branch but never pushed or cherry-picked back into the COMMON branch.</li>
<li>This was a similar issue to our 2nd point but manageable since the goal of the COMMON branch was to provide a template for further work and nothing more.</li>
<li>At the end of the day each controller is its own Individual Project and while the messages between them are same. The Hardware code does not need to be same.</li>
<li>This also prompted team-members to ask if we could delete unused hardware or logic file code (which wasn’t being used and was imported from the template). This was also fine and can be done during cleanup stage. However we eventually got used to the Modular system of our project so much so that we did not worry about the additional modules that were present in each branched controller project.</li>
</ol>

 

== '''Conclusion''' ==
CMPE243 gives one of the best experiences one could ever get in their academic life. The course is designed to give an insight into how the industry functions and enhances both technical and management skills. Apart from learning how to work and implement application of CAN protocol, one can get a hands-on experience with version control, unit-testing and software design. Overall it was a very great and memorable journey.

=== Project Video ===

Youtube Video at [https://youtu.be/zkTs8o7nB6k]

=== Project Source Code ===
* [https://gitlab.com/coder137/can-ster_truck GitLab Link]

=== Advise for Future Students ===
'''GENERAL:'''
* Form your team and start the project as early as you can.
* Clearly discuss what role each individual should do and ensure that progress is regularly tracked so that the team doesn't fall back on any schedule.
* Make sure your early structure of the project is decided. Before you start to write the code make sure that all the team and code guidelines are discussed. In our case we spent most of our first week deciding how we wanted to structure and design our code. This paid off in the long run since we had robust code inside one repository that could be extended efficiently.
* Make sure each module is individually testable i.e through periodic callbacks as well as unit-tests. While unit-tests can help for a lot of situations and provide a robust way to map the working of the module, it cannot simulate certain real-life scenarios. For example, Lidar buffer was constantly getting full due to the large number of incoming bytes. This caused us to have certain incorrect reading appear after a few minutes of the lidar running. Our solution was to minimize the <code>printf</code> statements inside the module that were used for debugging.
* Since lot of code and hardware integration is involved with this project, make sure testing is thoroughly and periodically done and make note of all the issues found.
'''HARDWARE:'''
* Decide on how you would power up the peripherals. We had issues with Bluetooth (not connecting), GPS (lock not happening) and LIDAR (giving incorrect values). After lot of cycles of hardware and software debugging, we found that the issue was with power. Choose wisely as to which peripherals must be connected to which power source.
* Isolate the power hungry devices to other parallel connections so that the voltage drop is not high. In our case the Graphical LCD and LIDAR were both very power hungry peripherals. The LCD used to start glitching incase there was a large voltage drop and the LIDAR used to give incorrect values or not update correctly. We solved this issue by giving the lidar a dedicated power supply.
* PCB design involves lot of hardware components. Coordinating with multiple team members and verifying each hardware connection takes quite some time. So start well ahead.
* Make sure to expose some extra GPIO and GND pins for future use.
'''MOTOR:'''
* You can use the LiPo battery to power the RPM and servo motor instead of using a separate power source. Use Vout from the ESC to get 6V.
* Start the PID control calibration early on as you will need to do extensive testing to get it working.

=== Acknowledgement ===
<HR>
Firstly we would like to express our gratitude to Professor Preetpal Kang for his guidance throughout the semester and providing us with this opportunity. We would also like to thank the ISA members Vignesh Kumar Venkateshwar and Aakash Vrajlal Chitroda for being available whenever in need and guiding us to complete the project.

== '''References''' ==
* CAN Reference [https://www.kvaser.com/about-can/can-dictionary/]
* FreeRTOS Reference [http://socialledge.com/sjsu/index.php/FreeRTOS_Tutorial]
* Git tutorial [http://socialledge.com/sjsu/index.php/Basic_Git_Tutorial]
* Unit-test reference [https://gitlab.com/sibros_public/public/-/wikis/c/unit_tests#lab-1]
* Getting started with SJ-Two [https://sjsu-dev2.readthedocs.io/en/latest/getting_started/getting_started/]

===Motor Controller===
* Traxxas User Manual: [https://images-na.ssl-images-amazon.com/images/I/D1NTpa7RNES.pdf]
* Traxxas Specification Sheet: [https://images-na.ssl-images-amazon.com/images/I/81WphBAuwIL.pdf]

===Geological Controller===
* Movable Scripts (Calculate distance, bearing and more between Latitude/Longitude points): [https://www.movable-type.co.uk/scripts/latlong.html]
* CMPS11 (I2C Configuration): [https://www.robot-electronics.co.uk/htm/cmps11i2c.htm]

===Bridge and Sensor Controller===
* [https://www.slamtec.com/en/Lidar/A1 LIDAR]
* [https://components101.com/ultrasonic-sensor-working-pinout-datasheet Ultrasonic sensor ]
===Driver and LCD Controller===
* LCD Software: [https://4dsystems.com.au/ulcd-32ptu 4Dsystems]
===Android===
* Youtube Channel: [https://www.youtube.com/channel/UCoNZZLhPuuRteu02rh7bzsw Coding with Mitch]
* Android Developers: [https://developer.android.com/guide/topics/connectivity/bluetooth Website][https://github.com/googlearchive/android-BluetoothChat Github]
* Udemy Course: [https://www.udemy.com/course/the-complete-android-oreo-developer-course/ Complete Android Oreo Developer Course]
===PCB Design===
* Design Tool: [https://easyeda.com/ EasyEDA]

S20: Canster Truck

2020-05-23T06:40:44Z

Proj user22: /* Hardware Design */

[[File:CMPE243_S20_T2_Canster_Truck_Logo.png|thumb|455px|caption|right|CAN-STER TRUCK LOGO]]

== '''Abstract''' ==
The Canster Truck Project is an autonomous RC car with CAN Bus interfaced controllers. The development of the RC car's subsystem modules (Interfacing of Ultrasonic Sensor, LIDAR, Bluetooth, GPS, Compass and CAN modules) was divided among six team members. The aim of the project is to develop an autonomous RC Car which can navigate from one source location to the selected destination on the app by avoiding obstacles in its path using sensors. Waypoints algorithm is used as the path finding technique.
 

== '''Introduction and Objectives''' ==

'''The project was divided into 7 modules:'''

* '''Bridge and Sensor Controller'''
* '''Motor Controller'''
* '''Geological Controller'''
* '''Driver and LCD Controller'''
* '''Hardware Integration'''
* '''Android Application'''
* '''Testing & Code Review'''

'''RC Car Objectives'''
'''1. Driver and LCD Controller''' - Handles algorithms for obstacle avoidance, route maneuvering, and waypoints
'''2. Geological Controller''' - Recieves coordinates from GPS and Heading from Compass for navigation
'''3. Motor Controller''' - Controls movements of the RC Car
'''4. Bridge and Sensor Controller''' - Detects surrounding objects and interfaces android application to controller via bluetooth
'''Team Objectives'''

[[File:CMPE243_S20_T2_High_Level_System_Diagram.png|thumb|center|800px| High Level System Diagram]]

 

== '''Team Members and Responsibilities''' ==
[[File:CMPE243_S20_T2_Canster Truck_Team.jpg|thumb|center|800px| Group Picture]]

'''Gitlab Project Link''' - [https://gitlab.com/coder137/can-ster_truck '''Canster Truck''']
 

*'''Niket Naidu''' [https://www.linkedin.com/in/niket-naidu-30090a134/ LinkedIn] [https://gitlab.com/coder137 Gitlab]
** '''Geological Controller''' : GPS, Compass, Waypoint Algorithm, Haversine and Bearing Angle logic
** '''Driver and LCD Controller''' : GLCD
** '''Bridge and Sensor Controller''' : Bluetooth
** '''Testing & Code Review'''

*'''Ganesh Ram Pamadi''' [https://www.linkedin.com/in/ganeshram93/ LinkedIn] [https://gitlab.com/ganeshram2493 Gitlab]
** '''Hardware Integration'''
** '''Testing & Code Review'''
** '''Driver Controller'''
** '''Motor Controller'''

*'''Nikhil Pabbisetty''' [https://www.linkedin.com/in/nikhilpabbisetty/ LinkedIn] [https://gitlab.com/nikhilpeoria Gitlab]
** '''Bridge and Sensor Controller'''
** '''Motor Controller'''
** '''Driver and LCD Controller'''
** '''Hardware Integration'''

*'''Akhil Cherukuri''' [https://www.linkedin.com/in/akhilcherukuri/ LinkedIn] [https://gitlab.com/akhilcherukuri Gitlab] [https://github.com/akhilcherukuri Github]
** '''Android Application'''
** '''Bridge and Sensor Controller'''

*'''Ashish Anant Ladage''' [https://www.linkedin.com/in/ashish-anant-ladage-7bb3a214b/ LinkedIn] [https://gitlab.com/ashishladage1 Gitlab]
** '''Driver and LCD Controller'''
** '''Hardware Integration'''
** '''Motor Controller'''

*'''Jesus De Haro De Reza''' [https://www.linkedin.com/in/jesus-de-haro-66342424/ LinkedIn] [https://gitlab.com/deharo27 Gitlab]
** '''Bridge and Sensor Controller'''
** '''Motor Controller'''

 

== '''Administrative Responsibilities''' ==
* '''Team Lead''' - [https://www.linkedin.com/in/niket-naidu-30090a134/ '''Niket Naidu''']
* '''Git Repository Manager''' - [https://www.linkedin.com/in/niket-naidu-30090a134/ '''Niket Naidu''']
* '''Bill Of Materials Manager''' - [https://www.linkedin.com/in/akhilcherukuri '''Akhil Cherukuri''']
* '''Wiki Report Manager''' - [https://www.linkedin.com/in/akhilcherukuri '''Akhil Cherukuri''']

 

== '''Schedule''' ==

{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-

! scope="row"| '''1'''
| style="text-align:center;" |'''02/11/2020'''
| style="text-align:center;" |'''02/17/2020'''
|
*'''Form teams and decide group name'''
*'''Review past projects'''
*'''Slack: Create project group and invite Preet'''
*'''GitLab: Create project groups repository'''
*'''Analysis of component required'''

|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''2'''
| style="text-align:center;" |'''02/18/2020'''
| style="text-align:center;" |'''02/24/2020'''
|
*'''Study CAN Communication'''
*'''Create Bill of Materials'''
*'''Order RC Car'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''3'''
| style="text-align:center;" |'''02/25/2020'''
| style="text-align:center;" |'''03/02/2020'''
|
*'''Setup team finance management using Splitwise application'''
*'''Complete Bill of Materials'''
*'''Order all other required components'''
*'''Wikipedia: Setup project report template'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''4'''
| style="text-align:center;" |'''03/03/2020'''
| style="text-align:center;" |'''03/09/2020'''
|
*'''Read the respective datasheets and manuals for each component'''
*'''Test each component for working conditions'''
|
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''5'''
| style="text-align:center;" |'''03/10/2020'''
| style="text-align:center;" |'''03/16/2020'''
|
*'''Assign team responsibilities and roles'''
*'''Setup team project management environment (ClickUp)'''
*'''Define CAN DBC'''
*'''Research GPS antennas and order'''
*'''Android: Environmental setup of Android Studio and enable version control'''
*'''Hardware : Decide PCB editing software (easyEDA)'''
*'''Hardware : Draft schematic for required PCB design'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''6'''
| style="text-align:center;" |'''03/17/2020'''
| style="text-align:center;" |'''03/23/2020'''
|
*'''Hardware : Create model of PCB''' 
*'''Android: Add a Button for changing bluetooth connection status in the application''' 
*'''Geological: Interface Compass module with SJ-2 board using I2C interface''' 
*'''Geological: Interface GPS module with SJ-2 board using the UART interface''' 
*'''Geological: Parse raw data to get meaningful values for GPS and Compass''' 
*'''Sensor: Interface and check the functionality of ultrasonic sensors to the SJ-2 board''' 
*'''Motor: Interface of Servo & DC motor to the SJ-2 board and check for basic functionality''' 
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''7'''
| style="text-align:center;" |'''03/24/2020'''
| style="text-align:center;" |'''03/30/2020'''
|
*'''Hardware : Finalize components placement on PCB.''' 
*'''Motor: Add PWM functionality and test the code on DC and servo motors''' 
*'''Sensor: Interface and check and study the output readings of Lidar sensor with SJ-2 board over UART''' 
*'''LCD Display: Explore UI designing of LCD''' 
*'''Hardware: Finalize on optimal ultrasonic sensor placements''' 
*'''Android: Initiate Bluetooth communication and show staus via text view''' 
*'''Wikipedia: Establish final wiki schedule'''
*'''Complete CAN communication format for each controller and link DBC file to the Wiki'''
*'''Complete high-level system block diagram'''
*'''Complete unit-level block diagrams'''
*'''Bridge: Interface HC-5 bluetooth module with Sj-2 board using serial communicaton'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''8'''
| style="text-align:center;" |'''03/31/2020'''
| style="text-align:center;" |'''04/06/2020'''
|
*'''Hardware: Analyze PCB model and order PCB Circuit board''' 
*'''Android: Initiate Bluetooth communication and send "Hello World".''' 
*'''Wikipedia: Start adding information/images/diagrams to the relevant sections'''
*'''Motor: Configure ESC for correct speed outcome according to frequency & PWM values''' 
*'''Motor: Finish RPM sensor hardware and software implementation and integration''' 
*'''Sensor: Read output from Lidar and setup structure for outputting for DBC''' 
*'''Geological: Implement waypoints algorithm''' 
*'''Driver: Implement obstacle avoidance algorithm''' 
*'''Bridge: Pass data such as "Hello World" from HC-05 bluetooth module to bluetooth terminal android application'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''9'''
| style="text-align:center;" |'''04/07/2020'''
| style="text-align:center;" |'''04/13/2020'''
|
*'''Hardware: Remove Unused parts from RC Car''' 
*'''Hardware: Mount PCB and 3D Parts''' 
*'''Motor: Decide different cut-off values from sensor to command right /slight right/ straight/ slight left/ left to motor.''' 
*'''Android: Embed Google Maps API for setting the car's destination.''' 
*'''LCD: Work to show RC cars live status information(battery level, current speed, long, lat, bearing, sensor data, etc)''' 
*'''Driver: Test obstacle avoidance algorithm and fine-tune sensor readings''' 
*'''Geological: Test checkpoint algorithm''' 
*'''Bridge: Establish two way communication between android application and bluetooth module''' 
*'''Update Bill of Materials for miscellaneous hardware'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''10'''
| style="text-align:center;" |'''04/14/2020'''
| style="text-align:center;" |'''04/20/2020'''
|
*'''Hardware: Integrate all hardware modules''' 
*'''LCD: Testing & Validation of the LCD UI and display vehicle status information''' 
*'''Android: Send car location to the app and checkpoints received to Geo module''' 
*'''Motor: Optimize PID control by accelerating/decelerating as instructed by Driver''' 
*'''Bridge: Configure HC-05 for auto reconnection if bluetooth communication disconnects''' 
*'''Add multiple debug messages and transmit on CAN'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''11'''
| style="text-align:center;" |'''04/21/2020'''
| style="text-align:center;" |'''04/27/2020'''
|
*'''Android: Send additional vehicle status information from RC car to the Application for display''' 
*'''Android: Finalize User Interface Design and Icon''' 
*'''Continuously test the whole system and handling of corner cases (outside).'''
*'''Finalize RC Car For Project Proto 1'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''12'''
| style="text-align:center;" |'''04/28/2020'''
| style="text-align:center;" |'''05/04/2020'''
|
*'''Gitlab: Push final code'''
*April 28th: Project Proto 1
*'''Finalize RC Car for Project Demo'''
*May 1st: Project Presentation
*'''Finalize RC Car for Project Proto 2'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''13'''
| style="text-align:center;" |'''05/05/2020'''
| style="text-align:center;" |'''05/21/2020'''
|
* '''Complete Individual Contribution Peer Grading'''
* '''Review and Complete Wiki Project Page'''
|
*'''Completed'''
*'''Completed'''
|-
|}

 

== '''Bill Of Materials''' ==
{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Item#
! scope="col"| Part Description
! scope="col"| Part Model & Vendor
! scope="col"| Quantity
! scope="col"| Cost in USD
|-
! scope="row"| 1
| '''Microcontroller Boards'''
| SJ2 Boards (Purchased from Preet Kang)
| 4
| $200.00
|-
! scope="row"| 2
| '''CAN Transceivers'''
| [https://www.waveshare.com/sn65hvd230-can-board.htm Waveshare SN65HVD230]
| 12
| $54.48
|-
! scope="row"| 3
| '''RC Car'''
| [https://www.amazon.com/Traxxas-Slash-Course-2-4GHZ-Vehicle/dp/B01DU474B0/ref=sr_1_3?ie=UTF8&qid=1474747759&sr=8-3&keywords=Traxxas+1%2F10+slash+2wd Traxxas 2WD RTR with 2.4Ghz Radio]
| 1
| $260.00
|-
! scope="row"| 4
| '''Lithium-Ion Battery'''
| [https://www.rcsuperstore.com/traxxas-7600mah-2s-7-4v-25c-id-lipo-battery-pack/ Traxxas 7600mAh 2S 7.4V 25C iD LiPo Battery Pack]
| 1
| $75.00
|-
! scope="row"| 5
| '''Lithium-Ion Battery Charger'''
| [https://www.amazon.com/Traxxas-2970-EZ-Peak-Charger-Identification/dp/B00OAFYLJC/ref=pd_bxgy_21_img_2?ie=UTF8&psc=1&refRID=JVX791WVV9Y8T9DW92KW Traxxas 2970 EZ-Peak Plus 4-Amp NiMH/LiPo Fast Charger]
| 1
| $50.00
|-
! scope="row"| 6
| '''Compass Breakout Board'''
| [https://www.dfrobot.com/product-1275.html DFRobot CMPS11 Compass]
| 1
| $29.99
|-
! scope="row"| 7
| '''Bluetooth Breakout Board'''
| [https://www.amazon.com/HC-05-Bluetooth-Pass-through-Wireless-Communication/dp/B01G9KSAF6/ref=sr_1_4?ie=UTF8&qid=1507077325&sr=8-4&keywords=arduino+bluetooth+hc-05 DSD TECH Bluetooth HC-05]
| 1
| $8.49
|-
! scope="row"| 8
| '''LIDAR Sensor'''
| [https://www.amazon.com/RPLiDAR-A1M8-Degree-Laser-Scanner/dp/B07H7X3SFF/ref=sr_1_fkmrnull_1?crid=2FSUI76G4UA8K&keywords=rplidar+a1m8+-+360+degree+laser+scanner+development+kit&qid=1552764172&s=gateway&sprefix=RPlidar%2Caps%2C263&sr=8-1-fkmrnull SEEED STUDIO RPLIDAR A1M8]
| 1
| $109.99
|-
! scope="row"| 9
| '''RPM Sensor'''
| [https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM Traxxas 6520 RPM Sensor]
| 1
| $13.70
|-
! scope="row"| 10
| '''GPS Breakout Board'''
| [https://www.adafruit.com/product/746 Adafruit Ultimate GPS Breakout v3]
| 1
| $44.30
|-
! scope="row"| 11
| '''LCD Display'''
| [https://4dsystems.com.au/ulcd-32ptu 4Dsystems 3.2 TFT-LCD ULCD-32PTU]
| 1
| $79.00
|-
! scope="row"| 12
| '''Ultrasonic Sensors'''
| [https://www.amazon.com/gp/product/B01COSN7O6/ ELEGOO HC-SR04 Ultrasonic Module]
| 5
| $12.00
|-
! scope="row"| 13
| '''GPS Antenna'''
| [https://www.amazon.com/dp/B07RRT615K/ GPS Antenna A1-UX]
| 1
| $10.98
|-
! scope="row"| 14
| '''PCB Fabrication'''
| [https://jlcpcb.com/ JLCPCB]
| 5
| $40.15
|-
! scope="row"| 15
| '''Miscellaneous'''
| [https://www.amazon.com Amazon],[https://www.mouser.com/ Mouser Electronics],[https://www.digikey.com/ Digikey],[https://anchor-electronics.com/ Anchor Electronics]
| ~
| $48.07
|-
! scope="row"|
|
|
| '''Total'''
| '''$1036.15'''
|-

|}

 

== '''Printed Circuit Board''' ==

=== Design And Architecture ===
The complete PCB (for boards and hardware peripherals) was designed using EasyEDA online software. The 4 nodes will be communicating via CAN bus and other peripherals are connected to the PCB via headers.

=== Power Section===
We have 2 power banks supplying our system. And the Servo Motor, RPM sensor and DC rear Motor (via ESC) are powered using LiPo battery (6 volts).
* Power bank #1 - Subset 2

* Power bank #2 - Subset 1, Subset 3, Bluetooth Module

'''NOTE:'''

'''Subset 1:'''
1. LIDAR
2. LCD
3. Compass

'''Subset 2:'''
1. Motor node
2. Driver node
3. BS node

'''Subset 3:'''
1. Geo node
2. Back ultrasonic sensor

=== Fabrication ===
* PCB was sent to fabrication to JLCPCB China which provided PCB with MOQ of 5 and 2 layers of PCB and common grounded the rest of the copper area.
'''DRC elements (in mils)'''
* Track Width = 12
* Clearance = 10
* Via Diameter = 24
* Via Drill Diameter = 12

=== Challenges ===
* Auto-routing gave lot of challenges (only ~60% success) and sometimes the online server even crashes and faces downtime. Even local routing had lot of issues. So make sure to plan your design accordingly.
* We started our PCB design well ahead of the project. So lot of pre-planning had to be done with regard to final hardware and placement of components in order to avoid spending extra time and money while re-ordering.
* The PCB went through a lot of internal revisions even before placing order. This was time-consuming.

'''Other hardware challenges:'''
* Figuring out why various hardware peripherals (GPS, Bluetooth, LIDAR and Ultrasonic sensor) started to malfunction (devices were on but values were either inconsistent / not occurring), took a lot of time to debug. It was due to insufficient power.

 
[[File:CMPE243 S20 T2 EasyEDA.png|1040x1200px|thumb|center|PCB Layout Design in EasyEDA]]
 
[[File:CMPE243 S20 T2 PCB SCHEMATIC.jpg|1041x550px|thumb|center|PCB Schematic]]
 
[[File:CMPE243 S20 T2 PCBFRONT.jpg|thumb|center|600px|PCB Top Layer]]
 
[[File:CMPE243 S20 T2 PCBBACK.jpg|thumb|center|600px|PCB Bottom Layer]]

 

== '''CAN Communication''' ==

=== Hardware Design ===
[[File:CMPE243_S20_T2_Canster_Truck_CANHW.png|thumb|center|770px| CAN Hardware Diagram]]

=== DBC File ===

DBC FILE: [https://gitlab.com/coder137/can-ster_truck/-/blob/dbc-improvements/projects/lpc40xx_freertos/project.dbc Gitlab]

<pre>
VERSION ""

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

BS_:

BU_: DBG DRIVER IO MOTOR SENSOR GEO

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" GEO,MOTOR,SENSOR

BO_ 101 GEO_HEARTBEAT: 1 GEO
SG_ GEO_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,MOTOR,SENSOR

BO_ 102 MOTOR_HEARTBEAT: 1 MOTOR
SG_ MOTOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,SENSOR

BO_ 103 SENSOR_HEARTBEAT: 1 SENSOR
SG_ SENSOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,MOTOR

BO_ 200 MOTOR_STEERING: 1 DRIVER
SG_ MOTOR_STEERING_direction: 0|8@1- (1,0) [-2|2] "" MOTOR

BO_ 210 DRIVER_COORDINATES: 8 DRIVER
SG_ DRIVER_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
SG_ DRIVER_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 220 MOTOR_SPEED: 1 DRIVER
SG_ MOTOR_SPEED_processed: 0|8@1- (1,0) [-3|3] "" MOTOR

BO_ 300 GEO_DEGREE: 8 GEO
SG_ GEO_DEGREE_current: 0|32@1+ (0.000001,0) [0|360] "degrees" DRIVER
SG_ GEO_DEGREE_required: 32|32@1+ (0.000001,0) [0|360] "degrees" DRIVER

BO_ 310 GEO_DESTINATION_REACHED: 1 GEO
SG_ GEO_DESTINATION_REACHED_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 400 MOTOR_SPEED_FEEDBACK: 4 MOTOR
SG_ MOTOR_SPEED_current: 0|32@1+ (0.1,0) [0|60] "kph" DRIVER

BO_ 500 SENSOR_BT_COORDINATES: 8 SENSOR
SG_ SENSOR_BT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
SG_ SENSOR_BT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 510 SENSOR_SONARS: 8 SENSOR
SG_ SENSOR_SONARS_left: 0|21@1+ (0.001,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right: 21|21@1+ (0.001,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle: 42|21@1+ (0.001,0) [0|0] "cm" DRIVER

BO_ 520 SENSOR_LIDAR: 8 SENSOR
SG_ SENSOR_LIDAR_middle: 0|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_slight_left: 16|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_slight_right: 32|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_back: 48|16@1+ (1,0) [0|0] "cm" DRIVER

BO_ 530 MOTOR_KEY: 1 SENSOR
SG_ MOTOR_KEY_val: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 900 GEO_CURRENT_COORDINATES: 8 GEO
SG_ GEO_CURRENT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" DBG
SG_ GEO_CURRENT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" DBG

BO_ 901 GEO_DISTANCE_FROM_DESTINATION: 4 GEO
SG_ GEO_distance_from_destination: 0|32@1+ (0.001,0) [0|0] "meters" DBG

BO_ 902 MOTOR_INFO_DBG: 4 MOTOR
SG_ MOTOR_INFO_DBG_rps: 0|16@1+ (1,0) [0|0] "" DBG
SG_ MOTOR_INFO_DBG_pwm: 16|16@1+ (0.001,0) [0|0] "" DBG

BO_ 903 LIPO_BATTERY_VOLTAGE_DBG: 4 MOTOR
SG_ LIPO_BATTERY_VOLTAGE_val: 0|32@1+ (0.01,0) [0|0] "volts" DBG

BO_ 904 CURRENT_CHECKPOINT_DBG: 1 GEO
SG_ CURRENT_CHECKPOINT_val: 0|8@1+ (1,0) [0|0] "" DBG

CM_ "--BU (Network Node) Information--";
CM_ BU_ DRIVER "The driver controller of the car";
CM_ BU_ GEO "The geo controller of the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";

CM_ "--BO (Message) Information--";
CM_ BO_ 100 "Driver Sync message used to synchronize the controllers";
CM_ BO_ 101 "Geo Sync message used to synchronize the controllers";
CM_ BO_ 102 "Motor Sync message used to synchronize the controllers";
CM_ BO_ 103 "Sensor Sync message used to synchronize the controllers";

CM_ BO_ 200 "Steering direction values sent by Driver Node to Motor Node";
CM_ BO_ 210 "Driver Destination coordinates sent by Driver Node";
CM_ BO_ 220 "Required motor speed computed from Driver Node to Motor Node";

CM_ BO_ 300 "Current and computer/required degree values sent by Geo Node";
CM_ BO_ 310 "Indicator signal to check if the RC car has reached the destination";

CM_ BO_ 400 "Current motor info (rps and kph) sent as feedback to the Driver Node";

CM_ BO_ 500 "Coordinate BT values (destination coordinates) sent by Sensor Node";
CM_ BO_ 510 "LIDAR - Distance from obstacle detected in each sector";
CM_ BO_ 520 "Ultrasonic Sensor - Distance from obstacle detected by each sensor";
CM_ BO_ 530 "Start/Stop signal from the Bluetooth app";

CM_ BO_ 900 "Destination coordinates for BUSMASTER debugging";
CM_ BO_ 901 "Distance from destination";
CM_ BO_ 902 "Supplied PWM value to the motor and its RPM";
CM_ BO_ 903 "LIPO Battery Voltage";
CM_ BO_ 904 "Current checkpoint of the car";

CM_ "--SG (Signal) Information for Heartbeats--";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver node";
CM_ SG_ 101 GEO_HEARTBEAT_cmd "Heartbeat command from the geological node";
CM_ SG_ 102 MOTOR_HEARTBEAT_cmd "Heartbeat command from the motor node";
CM_ SG_ 103 SENSOR_HEARTBEAT_cmd "Heartbeat command from the sensor node";

CM_ "--SG (Signal) Information for DRIVER Node--";
CM_ SG_ 200 DRIVER_STEERING_direction "Calculated Driver Steering values (-2,2) for Motor";
CM_ SG_ 210 DRIVER_COORDINATES_latitude "Destination Latitude coordinate";
CM_ SG_ 210 DRIVER_COORDINATES_longitude "Destination Longitude coordinate";
CM_ SG_ 220 MOTOR_SPEED "Calculated Driver speed values (-3,3) for Motor";

CM_ "--SG (Signal) Information for GEO Node--";
CM_ SG_ 300 GEO_DEGREE_current "Current Geo Degree relative to true north";
CM_ SG_ 300 GEO_DEGREE_required "Calculated Geo Degree computed by Haversine Formula";
CM_ SG_ 310 GEO_DESTINATION_REACHED "Indicator signal to check if the RC car has reached the destination";

CM_ "--SG (Signal) Information for MOTOR Node--";
CM_ SG_ 400 MOTOR_SPEED_FEEDBACK "Feedback speed (kph) sent by Motor Node";

CM_ "--SG (Signal) Information for SENSOR Node--";
CM_ SG_ 500 SENSOR_BT_COORDINATES_latitude "Destination Latitude received over Bluetooth";
CM_ SG_ 500 SENSOR_BT_COORDINATES_longitude "Destination Longitude received over Bluetooth";
CM_ SG_ 510 SENSOR_SONARS_left "Ultrasonic Sensor attached to the left side";
CM_ SG_ 510 SENSOR_SONARS_right "Ultrasonic Sensor attached to the right side";
CM_ SG_ 510 SENSOR_SONARS_middle "Ultrasonic Sensor attached to the middle";
CM_ SG_ 510 SENSOR_SONARS_back_left "Ultrasonic Sensor attached to the back left side";
CM_ SG_ 510 SENSOR_SONARS_back_right "Ultrasonic Sensor attached to the back right side";
CM_ SG_ 520 SENSOR_LIDAR_middle "Lidar sensing the middle sector (-15 to 15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_left "Lidar sensing the slight left sector (-45 to -15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_right "Lidar sensing the slight right sector (15 to 45 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_back "Lidar sensing the back of the car (165 to 195 degrees)";
CM_ SG_ 530 MOTOR_KEY_val "1 -> Start the motor from the app, 0 -> Stop";

CM_ SG_ 900 GEO_CURRENT_COORDINATES_latitude "Current Latitude";
CM_ SG_ 900 GEO_CURRENT_COORDINATES_longitude "Current Longitude";
CM_ SG_ 901 GEO_distance_from_destination "Distance from destination";
CM_ SG_ 902 MOTOR_INFO_DBG_rps "Current RPS value of the motor";
CM_ SG_ 902 MOTOR_INFO_DBG_pwm "Supplied motor PWM value";
CM_ SG_ 903 LIPO_BATTERY_VOLTAGE_val "LIPO Battery Voltage";
CM_ SG_ 904 CURRENT_CHECKPOINT_val "Current checkpoint of the car";

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

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

BA_ "GenMsgCycleTime" BO_ 100 1000;
BA_ "GenMsgCycleTime" BO_ 200 50;
BA_ "FieldType" SG_ 100 DRIVER_HEARTBEAT_cmd "DRIVER_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 102 GEO_HEARTBEAT_cmd "GEO_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 103 MOTOR_HEARTBEAT_cmd "MOTOR_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 104 SENSOR_HEARTBEAT_cmd "SENSOR_HEARTBEAT_cmd";

BA_ "FieldType" SG_ 200 MOTOR_STEERING "MOTOR_STEERING";
BA_ "FieldType" SG_ 230 MOTOR_SPEED_val "MOTOR_SPEED_val";
BA_ "FieldType" SG_ 310 GEO_DESTINATION_REACHED_cmd "GEO_DESTINATION_REACHED_cmd";

VAL_ 100 DRIVER_HEARTBEAT_cmd 2 "DRIVER_HEARTBEAT_cmd_REBOOT" 1 "DRIVER_HEARTBEAT_cmd_SYNC" 0 "DRIVER_HEARTBEAT_cmd_NOOP" ;
VAL_ 101 GEO_HEARTBEAT_cmd 2 "GEO_HEARTBEAT_cmd_REBOOT" 1 "GEO_HEARTBEAT_cmd_SYNC" 0 "GEO_HEARTBEAT_cmd_NOOP";
VAL_ 102 MOTOR_HEARTBEAT_cmd 20 "MOTOR_HEARTBEAT_cmd_REBOOT" 10 "MOTOR_HEARTBEAT_cmd_SYNC" 0 "MOTOR_HEARTBEAT_cmd_NOOP" ;
VAL_ 103 SENSOR_HEARTBEAT_cmd 200 "SENSOR_HEARTBEAT_cmd_REBOOT" 100 "SENSOR_HEARTBEAT_cmd_SYNC" 0 "SENSOR_HEARTBEAT_cmd_NOOP" ;

VAL_ 200 MOTOR_STEERING_direction -2 "MOTOR_STEERING_hard_left" -1 "MOTOR_STEERING_slight_left" 0 "MOTOR_STEERING_straight" 1 "MOTOR_STEERING_slight_right" 2 "MOTOR_STEERING_hard_right";
VAL_ 220 MOTOR_SPEED_processed -3 "MOTOR_SPEED_reverse_fast" -2 "MOTOR_SPEED_reverse_medium" -1 "MOTOR_SPEED_reverse_slow" 0 "MOTOR_SPEED_neutral" 1 "MOTOR_SPEED_forward_slow" 2 "MOTOR_SPEED_forward_medium" 3 "MOTOR_SPEED_forward_fast";
VAL_ 310 GEO_DESTINATION_REACHED_cmd 1 "GEO_DESTINATION_REACHED_cmd_REACHED" 0 "GEO_DESTINATION_REACHED_cmd_NOT_REACHED";
</pre>

 

== '''Motor Controller''' ==
'''[https://gitlab.com/coder137/can-ster_truck/-/tree/motor_bleeding_edge_dev GitLab Link]'''

This controller is used to control the components of the car-related to motor. We can control the speed and steering of the car having interfaced with various components with the SJ-2 board. The servo motor is controlled via PWM and is used to set the steering direction of the car. The DC motor is controlled by the Electronic Speed Controller (ESC) via PWM for speed. We read the speed of the car by using an RPM sensor. By using the RPM sensor values, a feedback loop has been designed to regulate the speed of the car. A state machine has been designed to manage the forward and backward movements of the car.
Additionally, a voltage divider circuit has been implemented to read the battery voltage. All motor functionality and CAN message communication is run at 10 Hz.

=== Hardware Design ===

[[File:CMPE243_S20_T2_Canster_Truck_Motor_Hardware.png|thumb|center|750px| Motor Hardware System]]

The following diagram details the hardware implementation of the motor module with the SJTwo board:
Hardware Interface
=====Servo Motor=====
The servo motor responds to PWM pulses. It has three pins namely Vcc, PWM Input Signal, and GND. The servo is powered using 6V from the car battery. Based on the PWM signal supplied from the SJTwo board the front wheels are turned.
[[File:CMPE243_S20_T2_Canster_Truck_Motor_1.jpg|440px|thumb|center|| Servo Motor]]
{| class="wikitable" style="text-align: center; width: 400px; height: 200px; margin: left;"
|+ Servo Motor Pin Connection
|-
! Sr. No.
! Wires - Servo Motor
! Function
|-
! 1
| PWM Connected to P2.5 || PWM Signal from Sj-2 Board
|-
! 2
| VCC || 6V supply from ESC
|-
! 3
| GND || Common Ground
|-
|}

=====Electronic Speed Controller (ESC)=====
The ESC is used to control the DC motor. It is supplied power using the 7.4 V LiPo battery. It has three pins namely Vout, PWM Input Signal, and GND. Based on the PWM input signal, the speed and forward, neutral, and backward movements of the car is changed. Vout is given to the RPM sensor and Servo motor.
[[File:CMPE243_S20_T2_Canster_Truck_Motor_2.jpg|440px|thumb|center|| Electronic Speed Controller (ESC)]]
{| class="wikitable" style="text-align: center; width: 400px; height: 200px; margin: left;"
|+ Speed Sensor Pin Connection
|-
! Sr. No.
! Wires - RPM Sensor
! Function
|-
! 1
| Signal Wire Connected to P2.0 || GPIO that supplies pulses to controller
|-
! 2
| VCC || 6V supply from ESC
|-
! 3
| GND || Common Ground
|-
|}

=====DC Motor=====
The DC motor is controlled using the ESC. It has two pins, a positive and a negative terminal. A PWM signal wire is connected to the microcontroller and the required current is provided by the LiPo battery and the ESC. The DC motor is controlled using PWM at 10Hz.

[[File:CMPE243_S20_T2_Canster_Truck_Motor_3.jpg|320px|thumb|center|| DC Motor]]
{|
|-
|
{| class="wikitable" style="text-align: center; width: 400px; height: 200px; margin-left:0px;"
|+ DC Motor Pin Connection
|-
! Sr. No.
! Wires - DC Motor
! Description
|-
! 1
| Positive Wire (already connected) || Positive Terminal
|-
! 2
| Negative Wire (already connected || Negative Terminal
|-
|}
 
{| class="wikitable" style="text-align: center; width: 400px; height: 200px;"
|+ DC Motor Configuration
|-
! Operation
! Pulse Width Range (ms)
! Duty Cycle(%)
|-
! FORWARD
| 1.51 - 2.00 || 15.1-20.0
|-
! STOP
| 1.50 || 15.0
|-
! REVERSE
| 1.00 - 1.49 || 10.0-14.9
|-
|}
|
|-
|}

Note: First calibrate the DC motor or the motor will not respond to your PWM pulses. For help with calibration go to this [https://traxxas.com/support/Programming-Your-Traxxas-Electronic-Speed-Control website]

=====RPM Sensor=====

The RPM sensor is used to get the current speed of the car. We use the info for creating a feedback loop (PID) for maintaining the speed of the car in uphill and downhill situations. The RPM sensor mounts on the rear DC motor shaft compartment with a special assembly also provided by Traxxas. The magnet which attached to the inner gear generates a pulse each rotation. The sensor works on the hall effect principle where it provides a current across its terminal when placed in a magnet's field. The RPM sensor has three pins namely Vcc, Signal, and GND.

[[File:CMPE243_S20_T2_Canster_Truck_Motor_4.jpg|440px|thumb|center|| RPM Sensor]]

{| class="wikitable" style="text-align: center; width: 400px; height: 200px; margin: left;"
|+ Speed Sensor Pin Connection
|-
! Sr. No.
! Wires - RPM Sensor
! Function
|-
! 1
| Signal Wire Connected to P2.2 || GPIO that supplies pulses to controller
|-
! 2
| VCC || 6V supply from ESC
|-
! 3
| GND || Common Ground
|-
|}

=== Software Design ===

The software for the motor node was divided into multiple files and made modular to improve readability and understanding of the complex logic involved. The main code modules are for:
*Servo Motor
*Electronic Speed Controller
*RPM Sensor
*Motor Wrapper
*Battery Voltage

The motor wrapper module is used to wrap all the code from the esc, servo, and rpm modules into simple to use functions to be called in the periodic tasks.
=====Servo Motor=====
It uses the steering value sent from the driver (-2 to 2) and matches it to the appropriate PWM value for steering. This code module is run at 10Hz.
<pre>
void servo__steer_processor(int16_t steering_value) {
switch (steering_value) {
case MOTOR_STEERING_hard_left:
servo__steer_hard_left();
break;
case MOTOR_STEERING_slight_left:
servo__steer_soft_left();
break;
case MOTOR_STEERING_straight:
servo__steer_straight();
break;
case MOTOR_STEERING_slight_right:
servo__steer_soft_right();
break;
case MOTOR_STEERING_hard_right:
servo__steer_hard_right();
break;
default:
printf("\nDid not receive steering value");
}
}
</pre>
=====Electronic Speed Controller=====

This code module is used to control the DC motor. It receives the motor direction value from the driver and sets the appropriate PWM value. Based on the value the motor is commanded to move the car forward or backwards. A switch case is implemented to set PWM values for movement in different directions along with different speeds.
<pre>
void esc__direction_processor(int16_t direction_value) {
desired_direction_value = direction_value;
switch (direction_value) {
case MOTOR_SPEED_reverse_fast:
esc__reverse_fast();
break;
case MOTOR_SPEED_reverse_medium:
esc__reverse_medium();
break;
case MOTOR_SPEED_reverse_slow:
esc__reverse_slow();
break;
case MOTOR_SPEED_neutral:
esc__neutral();
break;
case MOTOR_SPEED_forward_slow:
esc__forward_slow();
break;
case MOTOR_SPEED_forward_medium:
esc__forward_medium();
break;
case MOTOR_SPEED_forward_fast:
esc__forward_fast();
break;

default:
printf("\nDid not receive direction and speed value");
}
}
</pre>

There is also a feedback loop to control the speed. The ESC code depends on the rpm sensor code for the current speed values.
<pre>
double current_speed = get_speed_kph();
double desired_speed = desired_speed_kph;
float adjusted_duty_cycle = 0.0;
adjusted_duty_cycle = duty_cycle + (speed_to_pwm_adjustment(desired_speed, current_speed));
</pre>

[[File:CMPE243_S20_T2_Canster_Truck_Motor1.png|thumb|center|500px| Feedback Loop for Motor Speed]]

=====RPM Sensor=====
This code module is used to get current speed data from the RPM sensor. It is based on interrupts. When the wheel rotates once, we get one pulse due to the magnet installed. This pulse generates a falling edge interrupt during which we increment the pulse counter. Since, this code is run at 1Hz we collect the number of pulses generated every one second. This gives us the number of rotations per second using which we can calculate the speed in kph.
<pre>
float rpm__calculate_speed_kph() {
uint16_t rotation_per_sec = pulse_count;
pulse_count = 0;
speed_kph = ((CIRCUMFERENCE_METER * rotation_per_sec) * (MPS_TO_KPH_CONVERSION_FACTOR)) / GEAR_RATIO;
return speed_kph;
}
</pre>

=====Motor Wrapper=====
As mentioned above, the main function of this code module is to wrap all the other code modules and call the right functions at the appropriate frequency. The motor wrapper code also includes a state machine for ensuring a smooth transition between forward to backward state and vice versa. In order to achieve a smooth transition, a series of PWM pulses must be generated at the right time. For example, when the motor is moving from forward to backward state, a reverse value must be given first followed by at least three neutral values, and then continue with reverse values.

[[File:CMPE243_S20_T2_Canster_Truck_Motor2.png|thumb|center|500px| State Machine Flowchart for Motor Movements]]

=====LiPo Battery Voltage=====

The LiPo Battery Voltage was calculated using ADC in Burst Mode. A LiPo Hardware module was created for the same which contained two functions, <code>lipo__init</code> and <code>lipo__get_voltage</code>.

The voltage divider circuit is stepped down from 7.4V to 2.1V using 10K and 4K Resistor pair.
[[File:CMPE243_S20_T2_Canster Truck_Motor_Voltage_Regulator.png|thumb|center|400px| Voltage Regulator]]
'''LiPo Initialization'''

The LiPo Initialization phase initializes the ADC, Enables Burst mode on the ADC pins and configures the Alternate Function Registers for the same.

'''Getting LiPo Voltage'''

We read the raw ADC value from the LPC Hardware register. This value will be from 0 - 3.3V. However due to our voltage divider configuration the max voltage that we should theoretically get is 2.1V. This means that 2.1V corresponds to 7.4V of the LIPO Battery voltage.

The formula used is
<code>(raw_adc_value * MAX_LIPO_BATTERY_VOLTAGE_VALUE) / MAX_LIPO_ADC_VALUE</code>

=== Technical Challenges ===
<li>Changing movements of the car from Forward to Backward and vice versa
If you just change the PWM value from say 16 (Forward) to 14(Backward), the DC motor will just stop and will not make wheels turn reverse. We discovered this problem quite late as during the initial testing we had always run the car from the start with either forward or reverse but never tried changing the direction during run-time.
 
Solution: The motor requires a series of PWM pulses which is specific to the car to transition from forward mode to reverse mode. In our case we had to give the PWM pulses in the following sequence. Suppose,
<ol>
<li> Forward (16) (callback_count = 0)</li>
<li> Forward (16) (callback_count = 1)</li>
<li> Reverse (14) (callback_count = 2)</li>
<li> Neutral (15) (callback_count = 3)</li>
<li> Neutral (15) (callback_count = 4)</li>
<li> Neutral (15) (callback_count = 5)</li>
<li> Reverse (14) (callback_count = 6)</li>
<li> Continue reverse</li>
</ol>
Similarly, the reverse to forward can also be implemented.
<li>DC motor shooting off when there is an improper ground connection
When we connected the battery voltage circuit for reading the voltage from the battery, the motor would randomly shoot off every now and then.
 
Solution: Connect the voltage divider circuit to the common ground rather than taking the ground from the ESC.</li>

 

== '''Geological Controller''' ==
'''[https://gitlab.com/coder137/can-ster_truck/-/tree/geo_bleeding_edge_dev_waypoints GitLab Link]'''

===Messages===
*GEO_HEARTBEAT: Used to check for MIA by other nodes. Highest priority message for GEO Node

*GEO_DEGREE: Sends the current degree relative to the North Pole computed by the Compass and the Required degree relative to the North Pole computed by Bearing Angle using the Current Coordinate and Destination Coordinate.

*GEO_DESTINATION_REACHED: Sets a flag, 0 for destination not reached and 1 for destination reached

*GEO_CURRENT_COORDINATES: Debug Message used to send the Current GPS Coordinates

*GEO_DISTANCE_FROM_DESTINATION: Debug message used to send the Distance from Destination

*CURRENT_CHECKPOINT_DBG: Debug message used to check which checkpoint is being navigated to

=== Hardware Design ===

[[File:CMPE243_S20_T2_GEO1.png|thumb|center|650px| Geological Diagram]]

=== Software Design ===
=====Overview=====
*Inside the `periodic_callback__initialize`
**Initialize the CAN BUS
**Initialize the GPS

*Inside the `periodic_callback__1hz`
**Handle all MIA (from other Nodes)
**Update GPS LED when init and in case of failure
**Compute the GEO logic for Waypoints algorithm once every second (1000 ms)

*Inside the `periodic_callback__10hz`
**Handle CAN Incoming messages (Decode)
**Transmit CAN Geo messages (Encode and send)
**Compute the GPS Coordinate

=====Compass I2C Driver=====
An online datasheet resource was used to work with the Compass ([https://www.robot-electronics.co.uk/htm/cmps11i2c.htm CMPS11 Datasheet])
Initially the Compass I2C Driver was tested using the Terminal I2C Helper built by our Professor Preetpal Kang. Using this resource we were quickly able to read various I2C Registers and display it onto the terminal.

For our project the only required part of the Compass was the 16-bit Compass Bearing value (0-3599) i.e 0-359.9 degree values. These values were stored in the 2nd and 3rd register (Register 2 being the High Byte).
Once the raw data was received over I2C we could easily combine the data

<pre>
uint16_t bearing_value = (Reg2 << 8) | Reg3;
float rval = bearing_value / 10.0;
return rval;
</pre>
The returned value were transmitted to the Driver Node to compute its steering based on the required Bearing Angle.

=====GPS Initialization=====
GPS Initialization activates the Hardware GPIO (RX and TX), FreeRTOS Queue for UART Interrupts (UART Module) and Line Buffer Module to parse each GPS line.

=====GPS Data Parsing=====
The GPS Hardware module transmits an NMEA string over UART to the SJTwo Board. We read each character one by one and add it to the Line Buffer module.
Inside its computation loop, the Line Buffer module checks if a newline character has been received.
When a newline character has been received the entire string is extracted from the line buffer module and parsed according to its identifier ($GPRMC, $GPGGA) received and parsed into individual tokens.
For our purposes the $GPRMC NMEA string was the most appropriate and it helped us extract the Current Latitude Longitude as well as the Valid/Invalid tag for the Canster Truck.

=====GPS LED Indication for debugging=====

A simple module that checks for the GPRMC GPS Message and extracts the A or V valid (Tag). If $GPRMC NMEA string is valid, LED is set, else LED is reset. This gives us onsite debugging capabilities to know if GPS has locked onto a satellite signal.

=====GEO Logic Module Computation=====
The GEO Logic Module computes the Bearing Angle, Haversine Distance as well as the Waypoints algorithm.

'''Bearing Angle:'''

<code>
θ = atan2( sin Δλ ⋅ cos φ2 , cos φ1 ⋅ sin φ2 − sin φ1 ⋅ cos φ2 ⋅ cos Δλ )
</code>

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

Since atan2 returns values in the range -π ... +π (that is, -180° ... +180°), to normalize the result to a compass bearing (in the range 0° ... 360°, with −ve values transformed into the range 180° ... 360°), convert to degrees and then use (θ+360) % 360, where % is (floating point) modulo.
For final bearing, simply take the initial bearing from the endpoint to the start point and reverse it (using θ = (θ+180) % 360).

The above article reference gives us the required bearing angle that our car must align itself to, to reach a particular destination coordinate from its current coordinate.
The Steering of the vehicle depends on the above-computed angle values.

'''Haversine Distance Formula:'''

This uses the ‘haversine’ formula to calculate the great-circle distance between two points – that is, the shortest distance over the earth’s surface – giving an ‘as-the-crow-flies’ distance between the points (ignoring any hills they fly over, of course!).

<code>
a = sin²(Δφ/2) + cos φ1 ⋅ cos φ2 ⋅ sin²(Δλ/2)

c = 2 ⋅ atan2( √a, √(1−a) )

d = R ⋅ c
</code>

where φ is latitude, λ is longitude, R is earth’s radius (mean radius = 6,371km);
note that angles need to be in radians to pass to trig functions!

The above formula is used to calculate the distance between the source coordinate (received via GPS) and the destination coordinate.
Later this was used to compute the distance between source coordinate and each individual checkpoint to traverse the shortest distance.

'''Waypoints Algorithm:'''

The Waypoints algorithm that was chosen was a slightly modified version of Djikstra’s Algorithm.
3 values were calculated before the final computation

* Distance between source and final destination (DISTsd)
* Distance between source and each individual checkpoint (DISTsc)
* Distance between each individual checkpoint and the final destination. (DISTcd)

If '''DISTsd''' was lesser than '''DISTcd''', this checkpoint was discarded (we continue in the loop). Since we would be moving in the opposite direction, rather than towards the final destination.

If '''DISTsd''' was greater than '''DISTcd''', then we checked the nearest checkpoint to the source.
The minimum value was set initial that was equal to '''DISTsd'''.

If '''DISTsc''' was lesser than the minimum value stored, '''DISTsc''' would become the new minimum value, and the checkpoint index and coordinates would be appropriately stored and returned from the function.

In this way we would navigate to the nearest checkpoint from the source, while also making sure NOT to travel in the opposite direction.
This logic is recomputed only when we reach the checkpoint selected and the algorithm runs again to find the next checkpoint that we need to navigate to.

=====CAN Decode Destination Coordinates=====
Destination Coordinates are received from the Bridge and Sensor Node and transmitted over the CAN Bus. The value is decoded and stored in the GEO Logic Module.
This is a very important value since our entire GEO Logic calculations are based on the Destination Coordinate.

=====CAN Encode and Send=====

The main messages that were transmitter are
#Geo Degree
#Geo Destination Reached
#Distance from Destination Debug and Checkpoint Index debug

'''Geo Degree Computation as per Waypoints Algorithm:'''

Geo Degree was computed as per the current coordinates and the most recently computed checkpoint coordinates. This bearing angle calculation w.r.t computed checkpoint would continue till we do not reach that particular checkpoint.
Once we reach the computed checkpoint, Waypoint algorithm is recomputed as per the process mentioned above and the algorithm runs again.

'''Geo Destination Reached:'''

An Area of around 4 meters was set around the destination coordinate to check if the destination had been reached.
This measurement was taken into consideration to allow for the loss in precision when transmitting data over CAN as well as any irregularities that might occur when getting values from the GPS.
Having an area of 4 meters was very accurate for all of our test runs.

'''Geo Distance from Destination Debug and Checkpoint Index Debug:'''

Getting debug information was very critical to speed up our development process. In this case we could actively see if our algorithm worked properly.
The Geo Distance from Destination was used to see if we were moving closer to our destination or veering further away from it.
The Checkpoint Index was used to see which checkpoint index we were traveling to. By knowing the placements of the Individual checkpoints we could manually as well as programmatically (via Android application) verify the working of our Canster Truck.

=== Technical Challenges ===
#DBC Challenge for GEO Coordinates -> Could not encode more than 5-6 decimal places at a time, on later investigation we found that the 10000 is an int value, however 100000 overflows the int value.
#Creating an efficient algorithm for Waypoints, O(n) complexity.
#Getting appropriate fixes for GPS when not in a completely open space.
#GPS used to fluctuate or stop giving values when Battery voltage went below a particular threshold. Always supply 3.3V constantly at a good amperage.

 

== '''Sensor [Bridge and Sensor Controller]''' ==
'''[https://gitlab.com/coder137/can-ster_truck/-/tree/sensor_bleeding_edge_dev GitLab]'''
==='''Ultrasonic Sensor'''===
====Hardware Design====
This sensor uses an ultrasonic beam to measure the distances. Based on the time taken between when the beam is sent and received back to the sensor, the distance is calculated in the node.
Apart from 5v and GND, this sensor has 2 pins ECHO and TRIG which are interfaced with the SJ-Two board via GPIO.

[[File:CMPE243_S20_T2_CansterTruck_ultrasonic_sensor.jpg|thumb|center|300px| Ultrasonic Sensor Diagram]]

====Software Design====
* Init the GPIO pin connected to TRIG of the sensor as output and for ECHO as an input port.
* Attach the interrupt on the ECHO input port.
* Store the system_clock_count before setting the trigger pulse and then set the pulse. Also keep monitoring the input port.
* Take the system_clock_count at the instant of receiving the interrupt.
Distance = (system_clock_count_at_trig - system_clock_count_after_at_echo) / 57.14

==='''Lidar Sensor'''===
====Hardware Design====
The RPLidar sensor can be powered from a 5v source and uses UART communication to receive commands and transmit data. It has seven pins to interface with. Two sets of the pins (four total) are for power and ground. The remaining three are for UART receive and transmit, and for making the lidar’s motor spin.

[[File:CMPE243_S20_T2_Canster_Truck_RPLidar_A1.JPG|thumb|center|300px| RPLidar A1]]

====Software Design====
In terms of the lidar, the SJ2 initializes GPIO, UART, and memory for storing the measurement values. After initialization, the command to begin scanning is sent. Here, we wait for the lidar to send a response packet, letting the host (SJ2 board) know it received the command. The response packet the lidar sends will be 7 bytes. If the correct 7 bytes are not received, the command will be sent again.

[[File:CMPE243_S20_T2_Canster Truck_Lidar_flow.jpeg|thumb|center|200px| Lidar Flow]]

Following the response packet, the lidar begins sending 5-byte measurement data. Each sample contains a distance measurement (in millimeters) and the angle (with respect to the lidar) in which it was taken. The data packet structure is shown in the following figure. In addition to containing the distance and angle, the packet includes a quality value, to indicate the reliability of the measurement, and three check bits (S, ~S, and C). As the data is received via UART, we wait until we have 5 bytes before continuing to process. Before processing the 5 bytes after receiving them, the check bits are confirmed to be correct. If they are incorrect, it will not be processed and we will wait for another sample to be received.

[[File:CMPE243_S20_T2_Canster Truck_DataPacketStructure.JPG|thumb|center|200px| Data Packet Structure]]

In the case the sample is correct, each measurement value that is in a direction of interest will be placed in an array designated to one of four directions (left, right, front, rear). Each of these directions have their own sector in the lidar’s 360-degree view.
*Right sector: 11° - 30°
*Rear sector: 170° - 190°
*Left sector: 330° - 349°
*Front sector: 350° - 370° (or 10°)

The arrays mentioned will hold roughly 20 measurements, which are every degree in the sector. In the event, objects are too far to measure, the lidar will report 0 mm. distance. Since there is no measurable obstacle, a “large” distance value of 3000 mm. is placed in the array. The smallest distance value will be taken from each array and reported to the driver node for obstacle avoidance.

=== Technical Challenges ===
====Ultrasonic Sensor====
*'''Power issue''' The pulses were getting triggered incorrectly and it took a while to figure out that it was due to insufficient power.

====LIDAR====
*'''Datasheet not 100% clear:''' The correct datasheet for the was a bit difficult to obtain, and the manufacturer needed to be contacted. The first document found online was high level and general information about the sensor, but the manufacturer did provide another document that contained the information of the commands and responses to and from the lidar, and their packet structure. The documents did not clearly state the angles with respect to the lidar are fixed, which left me wondering if the lidar will think the direction it is facing when powered on will become the new “zeroth” angle.

*'''UART Buffer Overflow:''' When first interfacing with the sensor, the incoming bytes of the lidar were printed on to the terminal to make sure there was a response and to make sense of the information. Since the command we sent results in 5 bytes of data per measurement samples from the lidar and the lidar measured 2000 times per second, there are will be roughly 10k Bytes per second of data incoming that need to be handled continuously. With an improperly sized UART buffer and print statements it is guaranteed to occur, making the lidar data look like random values.

*'''Proper Parsing of Measurement Data:''' After sending a command to the lidar, the sensor will send a response packet, followed by the measurement data. The initial response from the lidar is a 7-byte packet, followed by continuous 5-byte measurement samples. I needed to make sure however I handled the response would be independent of how the measurement is handled, so as not to create a potential unwanted offset when receiving measurements.

*'''Object Detection with Received Data:''' Once proper communication was set up with the lidar and measurement data was getting decoded, there needed to be a way to measure when obstacles were present. If ~360 measurements are handled entirely independently from one another, it could become a complex and confusing code. To achieve a simple approach, four sectors about 20 degrees in size were used to represent the front, left, right, and rear directions.

*'''Bugs in Code:''' When first implementing the code, there were a few bugs from typos, incorrect numbers, and some faulty logic that were found with the use of unit testing. Unit testing helped find these issues and verified the logic was correct, and I would say gave me 90% confidence in my lidar handling.

 

== '''Bluetooth Module [Bridge and Sensor Controller]'''==

Bridge functionality of the Bridge and Sensor Controller is to establish wireless communication between the SJ-2 Board and the android mobile device using the HC-05 Bluetooth module. The Bridge controller will be receiving start command with destination GEO coordinates and stop command. The Bridge controller will be transmitting the required sensor data and debug information to be displayed on the android application.

[[File:CMPE243_S20_T2_BRIDGE.png|thumb|center|500px| Bridge Diagram]]

==== Software Design ====

'''Low-Level Layer'''

In this layer, similar to the GPS the UART GPIO was initialized (RX, TX), FreeRTOS Queue was initialized for UART Interrupts and the line buffer module was initialized to parse strings.

Two basic functions <code>bt__read</code> and <code>bt__write</code> were implemented.
As the name suggested, <code>bt__write</code> took a string as its input parameter and transmitted that data to the Android application. <code>bt__read</code> stored the incoming characters into the line buffer, parsed the line received into its identifier and tokens, and invoked a callback function.

Since this was a low-level layer the User would not be directly invoking this library. Instead a '''Bluetooth Wrapper''' module was created which would be invoked and used by the user.

'''Application Layer'''

The Bluetooth Wrapper module had the appropriate <code>read_once</code> and <code>write_once</code> functions.

The <code>read_once</code> function internally just called the <code>bt__read</code> function. All of the decodings was done inside the Callback Function.
To get the Destination coordinate the string received from the Android Application was in the form of
<code>$loc,<destination_latitude>,<destination_longitude>.</code>
Upon receiving this data we parsed the destination_latitude and destination_longitude, which could later be accessed using getters.
We also set a start flag to notify the Driver Node that destination has been received and we can start steering towards our checkpoints.

Another command implemented was the stop command.
<code>$stop</code>
This was used to send a stop flag to the Driver node.

The <code>write_once</code> function used the getter methods from each CAN Decode message and update its internal state variables. A CSV String was created using the <code>$canster</code> identifier and various debugging points were appended to this message using a comma.
On the Android application side this CSV string was tokenized and displayed onto the Application Debug screen appropriately.

==== Technical Challenges ====

'''Bluetooth peripheral not turning on'''
* We initially connected the Bluetooth module directly to the SJ-Two board with (Vcc = 3.3v). But it was not giving only 2.7v and hence the device did not turn on.
* We had to connect it to external power source to make it function without hassles.

 

== '''Driver [Driver and LCD Controller]''' ==
'''[https://gitlab.com/coder137/can-ster_truck/-/tree/driver_bleeding_edge_dev GitLab]'''

=== Software Design ===

[[File:CMPE243_S20_T2_Canster Truck_Driver_Flowchart.png|thumb|center|750px|Driver Flowchart]]

The above block diagram explains the process flow of obstacle detection for the car. The LIDAR detects
the obstacle and depending on the distance of obstacle the car takes a slight right and slight left or a
hard right and hard left. The state of the car also depends on the value of the LIDAR and ultrasonic sensor.
The loose ends of the LIDAR for the reverse condition are checked by the ultrasonic sensors. The
The ultrasonic sensor works on the principle of trigger and echo and can detect the obstacles very close by.
The range of the Ultrasonic sensor is lower than the LIDAR. Finally, if no obstacle is detected the car goes
straight until the destination is reached. The speed of the car is also various when an obstacle is detected to
avoid the crash and the car’s smooth transition from one state to another. The key to the android
application controls the start and stop the process of the car. If the key is not pressed, then the stays in the

neutral state. The speed of the car is controlled by the changing duty cycle of the input voltage. There
are seven-speed levels in which the motor can run on. These speed levels are Forward Slow, Medium,
Fast, Reverse Slow, Medium, Fast, and Neutral. The Neutral is the stop condition with a 0% duty cycle.

=== Technical Challenges ===

Technical Challenges faced during obstacle detection:

*Due to dimensions of the car and for the perfect obstacle avoidance the values of 100cm and 150cm had to be selected for the turning radius. Hence, it is very important to calibrate these values appropriately, as these values will be unique for different car designs.
*For a situation, where even if the lidar doesn’t detect any obstacle at the middle, the car must take a slight right or a slight left as per our design. This is the case where the obstacle can be a moving one and that is why the lidar middle couldn’t detect it.

 

== '''LCD [Driver and LCD Controller]''' ==
=== Hardware Design ===
[[File:CMPE243_S20_T2_Canster_Truck_LCD_Diagram.png|thumb|600px|center| LCD Design]]
{|style="text-align: center; width: 400px; height: 200px; margin: auto;"
|
[[File:CMPE243_S20_T2_Canster_Truck_GLCD.jpg|thumb|200px|center| GLCD Hardware]]
||
[[File:CMPE243_S20_T2_Canster_Truck_GLCD2.jpg|thumb|600px|center| GLCD Software Simulation (Initial Iteration)]]
|
|}

=== Software Design ===
The GLCD used was created by 4DSystems, using their IDE a UI was created. Each UI component could be controlled by sending UART data targeted at the widget address.
The best part about this GLCD was that we had a lot of interactive widgets to display debugging information in real-time.
The GLCD code was divided into 3 parts:

=====Low-Level Initialization=====
Initialize the low-level hardware interfaces to send and receive data from the GLCD.
Similar to the GPS and Bluetooth, The UART GPIO was initialized (RX, TX), FreeRTOS Queue was initialized for UART Interrupt and line buffer was used to get a stream of data for parsing.

Low-level '''read''' and '''write''' commands were used as per the working of the GLCD Module.
When Reading data pertaining to a widget on the GLCD we would need to send a particular response packet.

<pre>
void lcd__read(lcd_object_e object_id, uint8_t object_index, uint8_t *response, uint16_t *response_data) {

uint8_t checksum = READ_OBJ ^ object_id ^ object_index;
uint8_t buffer[] = {READ_OBJ, object_id, object_index, checksum};

lcd__write_data(buffer, sizeof(buffer) / sizeof(uint8_t));
lcd__read_response_id(response);
lcd__read_response_data(response_data);
}
</pre>

The response_data returned contains the Widget ID as well as the current value stored on that widget.

When Writing data pertaining to a widget on a GLCD the process is similar to the above mentioned code.
<pre>
void lcd__write(lcd_object_e object_id, uint8_t object_index, uint8_t msb, uint8_t lsb, uint8_t *response) {
uint8_t checksum = WRITE_OBJ ^ object_id ^ object_index ^ msb ^ lsb;
uint8_t buffer[] = {WRITE_OBJ, object_id, object_index, msb, lsb, checksum};

lcd__write_data(buffer, sizeof(buffer) / sizeof(uint8_t));
lcd__read_response_id(response);
}
</pre>

However in this case we receive only an ACK or NACK from the system. ACK would mean that the write to GLCD widget was successful and the widget now stored appropriate values. NACK would mean that a particular error has occurred. The errors could be regarding baud rate, incorrect bit format, incorrect index values, etc.

=====GLCD Wrapper for Widgets=====
The above low-level code had generic read and write functions. However for our UI we were only using 3 Widgets. All of which had '''different Indexes''' and '''Widget IDs'''.
Therefore a very simple library was created to easily interface with those widgets
<pre>
bool lcd_wrapper__read_led(uint8_t index);
uint16_t lcd_wrapper__read_meter(uint8_t index);
uint16_t lcd_wrapper__read_leddigit(uint8_t index);

bool lcd_wrapper__write_led(uint8_t index, bool value);
bool lcd_wrapper__write_meter(uint8_t index, uint16_t value);
bool lcd_wrapper__write_leddigit(uint8_t index, uint16_t value);
</pre>

The above code is self-explanatory read and write functions for '''LED''', '''METER''', and '''LED DIGIT'''.

=====GLCD UI=====
Now that we had our low level and Widget wrapper working properly, we wanted to create our Dynamic UI as well. The code would need to be robust enough to handle any UI that we create on the GLCD which could be reflected equivalently in our C Code.

<pre>
static void lcd_ui__update_ui(void) {

lcd_wrapper__write_led(LCD_LED_DRIVER_MIA_INDEX, driver_mia_led);
lcd_wrapper__write_led(LCD_LED_SENSOR_MIA_INDEX, sensor_mia_led);
lcd_wrapper__write_led(LCD_LED_GEO_MIA_INDEX, geo_mia_led);
lcd_wrapper__write_led(LCD_LED_MOTOR_MIA_INDEX, motor_mia_led);

// kph is always in the range of 0 - 10
lcd_wrapper__write_meter(LCD_METER_KPH_INDEX, kph_meter % 11);

// These will be in the Range of 0-99
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_RPM_INDEX, rpm_leddigit % 100);
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_CURRENTDEGREE_INDEX, cdegree_leddigit % 100);
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_REQUIREDDEGREE_INDEX, rdegree_leddigit % 100);
}
</pre>

As we can see the <code>lcd_ui__update_ui</code> function was called periodically inside the 1Hz function. It updated the screen in real time based on the static values that were stored AND updated inside the LCD UI module.
The Constant INDEX values stored were directly mapped onto the Index values were received from the 4DWorkshop UI Software.

=== Technical Challenges ===

*The GLCD needs to be supplied appropriate voltage (5V) at 1A for it to work properly. The LCD does not turn on without an appropriate power supply
*The GLCD UART interface has an additional RES signal. This RES signal resets the GLCD when pulled low. When connecting the UART display it is recommended to always reset the GLCD display for proper working
*The GLCD has a latency of up to 30ms when querying and receiving data. In our case, the real-time system has hard caps on time (i.e up to 1second of delay is possible on the 1Hz function)
*This was rectified by putting the read functions (if any) inside the low priority 1Hz periodic_callback function.
*Write operations do not suffer from such a latency issue since they only send one byte (ACK or NACK) signal back.
*Fortunately most of our logic involved just a write (setting a value on the GLCD) rather than reading or querying the widget.

 

== '''Android Application''' ==
[https://gitlab.com/akhilcherukuri/can-ster_truck_application Gitlab]
=== Software Design ===

<div><ul>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android4.jpg|thumb|none|220px|Info Activity (Top)]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android7.jpg|thumb|none|220px|Info Activity (Middle)]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android5.jpg|thumb|none|220px|Info Activity (Bottom)]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android6.jpg |thumb|none|220px|Debug Activity Screen]]</li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster_Truck_Android_GIF1.gif|thumb|center|220px|App Animations]]</li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster_Truck_Android_GIF2.gif|thumb|center|220px|Live Location]]</li>
</ul></div>
The application consists of a total of 5 Activities:

=====Main Activity=====
**This is the app launch display screen
**It will check for all the required permission onStart().
**Has search button for connecting from a paired device list view
**Once device is clicked, an intent will start the Map Activity
=====Map Activity=====
* For this requirement we are using the Google Maps Fragment, for the map fragment to function we must request an API key from Google and set the key in the manifest of the application.
* Destination marker(Red Marker) is set using <code>setOnMapClickListener</code> to which the car will navigate to, the destination can be changed by clicking elsewhere on the Map Fragment. The marker can be removed using <code>setOnMarkerClickListener</code>.
* When the start button is pressed, the start command identifier along with destination latitude and longitude is sent to the car via the write thread. A background thread is started along with it to indicate the current car's position(Green Marker) along with a plotline between the current position and destination.
* When the stop button is pressed, the stop command identifier is sent to the car, to stop and turn off the car.
=====Info Activity=====
* Messages from Geological, Driver, Motor coming from CAN bus are decoded by the Sensor and Bridge controller and sent to the Android application as a string.
* The received string is parsed and categorizes the data to store it in the required textView to be displayed.
* Bluetooth status, Lidar Values, Ultrasonic Sensor Values, Motor Speed, Motor RPM, Motor PWM, Cars' current location, Compass Heading, Distance till Destination, Checkpoint Index is displayed. This was useful for debugging purposes and allowed us to avoid scanning the mounted LCD or CAN Busmaster on PC during drives.
=====Debug Activity=====
*The main function of this activity is to check all RAW RX and RAW TX messages and create a log of all the data received and sent.
=====Bluetooth Connection Service Activity=====
*This is the background activity that handles all the threads required for transmission and receiving data using Bluetooth connections. It has 3 running threads which is called inside other activities using a handler:
* Accept Thread - Listens to BluetoothServerSocket using listenUsingRfcommWithServiceRecord. In order for the RF communication socket to connect to the HC-05, we used the following <code>UUID: 00001101-0000-1000-8000-00805F9B34FB</code>. This is a generic SSP Bluetooth UUID that enables the socket to directly connected to HC-05 and maintain the connection.
* Connect Thread - Creates a Bluetooth socket using createRfcommSocketToServiceRecord
* Connected Thread - Creates socket.getInputStream(); and socket.getOutputStream(); when bytes are available in input stream it will read them into a buffer.
**All messages for activities are done by <code> Handler mHandler.obtainMessage(); mHandler.sendMessage(); </code>

'''Receieved string:'''
* A String is sent to the Bluetooth app from HC-05 and when it receives a string with identifier "$canster", the message is prased accordingly by using the string delimiter ',' and is ended by the newline character '\n' which will remove the data from StringBuffer.
* <code>Example: $canster,37.339334,-121.881123,37.338713,-121.880685,10.123,20.133,30.123,10.5,88.1,99.2,-2,1,44,7,11,22,33,-3,23\n</code>

'''Manifest:'''
<pre>
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.INTERNET" />
</pre>

'''Dependencies:'''
<pre>
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'com.google.android.gms:play-services-maps:17.0.0'
compile 'com.google.maps.android:android-maps-utils:0.4+'
implementation 'androidx.cardview:cardview:1.0.0'
implementation 'com.google.android.gms:play-services-location:17.0.0'
implementation 'androidx.appcompat:appcompat:1.1.0'
implementation 'androidx.constraintlayout:constraintlayout:1.1.3'
implementation 'com.android.support:design:28.0.0'
implementation 'androidx.navigation:navigation-fragment:2.2.1'
implementation 'androidx.navigation:navigation-ui:2.2.1'
implementation 'androidx.lifecycle:lifecycle-extensions:2.2.0'
</pre>

[[File:CMPE243_S20_T2_BLUETOOTHFLOWCHART.png|thumb|center|650px| Android Application Flowchart]]

=== Technical Challenges ===
*'''Bluetooth Discovery:''' While creating the android application, we were not able to see any Bluetooth devices in the paired device list. The problem was that for the Android versions above Lillipop we would also need location access. We have solved it by writing a function to check whether to check for permissions or not.
<pre>
private void checkBluetoothPermissions() {
Log.d(TAG, "checkBTPermissions: Checking permissions");
int permission_check = this.checkSelfPermission("Manifest.permission.ACCESS_FINE_LOCATION");
permission_check += this.checkSelfPermission("Manifest.permission.ACCESS_COARSE_LOCATION");
if (permission_check != 0) {
this.requestPermissions(new String[]{Manifest.permission.ACCESS_FINE_LOCATION, Manifest.permission.ACCESS_COARSE_LOCATION}, 1001); //Any number
}
else{
Log.d(TAG, "checkBTPermissions: No need to check permissions. SDK version < LOLLIPOP.");
}
}
</pre>
*'''Catching NULL in a StringTokenizer: ''' When sending data using Bluetooth sometimes thee app crashes. Using debug Run log in Android Studio IDE, we have found out that this is because we get <code> NullPointerException, java.util.StringTokenizer </code> error. This is mainly due to passing a null value to the StringTokenizer constructor. This problem can be avoided by after reading a line from the Bluetooth StringBuffer, we check whether it is null, before passing it to the StringTokenizer, but later on, we have preferred to use <code>split();</code> to prase the received string as StringTokenizer is now a legacy class that is retained for compatibility reasons and its use is discouraged in new code.

*'''XML Layouts: ''' Generating layouts is difficult for new android code developers, the design layouts made should be compatible for a wide range of mobile devices but using the new android libraries we have found that, the older phones then tend to have difficulty in showing the layouts correctly. We have solved this problem by learning the design commercial XML design layouts by following tutorials on Udemy and Youtube.

*'''Auto Connect''': During the first stages we have implemented Bluetooth connection via searching for all devices and clicking on the device from Listpair to connect. This has a lot of time to process all the discovered devices near range. To solve this we have hardcoded the HC-05 device address <code>00:14:03:06:02:83</code> to <code>mBluetoothAdapter.getRemoteDevice("device address")</code>.

 

== '''Management''' ==
===Git Management===

Git Management amongst 6 team members was definitely a very challenging task. Depending on our initial design we could’ve had a lot of merge conflicts. However those risks were mitigated by spending a LOT of time in the initial stages to decide our pipeline and structure.

<li>There are certain components in our system that were COMMON. For example the CAN initialization, communication and decodes were all similar for the most part between all the 4 Controllers. The utility modules used were also similar in nature</li>
<li>Thus we made a common branch that contained the templates for CAN Nodes (not Controllers), Hardware code and Utility functions.
<ol>
<li>Later this common branch was forked into an individual Controller specific branch (SENSOR, GEO, MOTOR or DRIVER).</li>
<li>Only the Logic folder contained Controller specific code, specific to that controller.</li>
</ol>
<li>This gave us a lot of flexibility since all the team members had similar APIs to work with on all 4 branches. This promoted easy understanding and learning.
<ol>
<li>Many team members frequently worked on 2 or more controllers at a time where can messages were concerned. Having a APIs also meant that just the can_handler needed to be updated regularly followed by the equivalent logic code. </li>
<li>Inside the logic folder, getters to the can node modules were frequently used.</li></ol>

An example of how one of our initial templates was setup.
<pre>
├───can_module
│ ├───can_bus_initializer
│ ├───can_constants
│ ├───can_driver_node
│ ├───can_geo_node
│ ├───can_handler
│ ├───can_motor_node
│ ├───can_sensor_node
│ └───test
├───hardware
│ ├───bt
│ ├───compass
│ ├───gps
│ ├───lcd
│ ├───lidar
│ ├───motor
│ ├───test
│ └───ultrasonic
├───logic
│ ├───driver_obstacle
│ ├───driver_state
│ ├───geo_logic
│ └───test
└───utility
├───line_buffer
└───test
</pre>

'''Challenges'''
<li>It was initially a bit of a learning curve to understand the flow of the repository</li>
<li>When using a git management system with different versions in each branch it became very tough when the number of branches suddenly exploded in size. A lot of relevant code was stuck in a lot of different branches.
<ol>
<li>This happened mainly due to assignment submissions and unclosed MRs that eventually became stale.</li>
<li>Our strategy was to abandon these MRs and keep forking from these branches without merging it back into its final controller branch.</li>
<li>The latest branches that were kept were aptly named `<controller>_bleeding_edge_dev` branches since they were never merged back from where they were forked.</li>
</ol>
<li>Since a lot of our code also depended on the DBC autogenerated code, we could not suddenly change the DBC Message names once they were established since it caused a change in the Struct name that was generated and used.
<ol>
<li>Our solution to this was to keep everything backward compatible. We added new function names without deleting old DBC messages.</li>
<li>In certain places where we wanted to modify a function name it was done one by one so that a lot of the code is not broken at one time.</li>
</ol>
<li>Common Branches eventually became stale as our progress continued on the bleeding edge branches
<ol>
<li>For example certain GPS features needed to be added which were done on the GEO_bleeding_edge_dev branch but never pushed or cherry-picked back into the COMMON branch.</li>
<li>This was a similar issue to our 2nd point but manageable since the goal of the COMMON branch was to provide a template for further work and nothing more.</li>
<li>At the end of the day each controller is its own Individual Project and while the messages between them are same. The Hardware code does not need to be same.</li>
<li>This also prompted team-members to ask if we could delete unused hardware or logic file code (which wasn’t being used and was imported from the template). This was also fine and can be done during cleanup stage. However we eventually got used to the Modular system of our project so much so that we did not worry about the additional modules that were present in each branched controller project.</li>
</ol>

 

== '''Conclusion''' ==
CMPE243 gives one of the best experiences one could ever get in their academic life. The course is designed to give an insight into how the industry functions and enhances both technical and management skills. Apart from learning how to work and implement application of CAN protocol, one can get a hands-on experience with version control, unit-testing and software design. Overall it was a very great and memorable journey.

=== Project Video ===

=== Project Source Code ===
* [https://gitlab.com/coder137/can-ster_truck GitLab Link]

=== Advise for Future Students ===
'''GENERAL:'''
* Form your team and start the project as early as you can.
* Clearly discuss what role each individual should do and ensure that progress is regularly tracked so that the team doesn't fall back on any schedule.
* Make sure your early structure of the project is decided. Before you start to write the code make sure that all the team and code guidelines are discussed. In our case we spent most of our first week deciding how we wanted to structure and design our code. This paid off in the long run since we had robust code inside one repository that could be extended efficiently.
* Make sure each module is individually testable i.e through periodic callbacks as well as unit-tests. While unit-tests can help for a lot of situations and provide a robust way to map the working of the module, it cannot simulate certain real-life scenarios. For example, Lidar buffer was constantly getting full due to the large number of incoming bytes. This caused us to have certain incorrect reading appear after a few minutes of the lidar running. Our solution was to minimize the <code>printf</code> statements inside the module that were used for debugging.
* Since lot of code and hardware integration is involved with this project, make sure testing is thoroughly and periodically done and make note of all the issues found.
'''HARDWARE:'''
* Decide on how you would power up the peripherals. We had issues with Bluetooth (not connecting), GPS (lock not happening) and LIDAR (giving incorrect values). After lot of cycles of hardware and software debugging, we found that the issue was with power. Choose wisely as to which peripherals must be connected to which power source.
* Isolate the power hungry devices to other parallel connections so that the voltage drop is not high. In our case the Graphical LCD and LIDAR were both very power hungry peripherals. The LCD used to start glitching incase there was a large voltage drop and the LIDAR used to give incorrect values or not update correctly. We solved this issue by giving the lidar a dedicated power supply.
* PCB design involves lot of hardware components. Coordinating with multiple team members and verifying each hardware connection takes quite some time. So start well ahead.
* Make sure to expose some extra GPIO and GND pins for future use.
'''MOTOR:'''
* You can use the LiPo battery to power the RPM and servo motor instead of using a separate power source. Use Vout from the ESC to get 6V.
* Start the PID control calibration early on as you will need to do extensive testing to get it working.

=== Acknowledgement ===
<HR>
Firstly we would like to express our gratitude to Professor Preetpal Kang for his guidance throughout the semester and providing us with this opportunity. We would also like to thank the ISA members Vignesh Kumar Venkateshwar and Aakash Vrajlal Chitroda for being available whenever in need and guiding us to complete the project.

== '''References''' ==
* CAN Reference [https://www.kvaser.com/about-can/can-dictionary/]
* FreeRTOS Reference [http://socialledge.com/sjsu/index.php/FreeRTOS_Tutorial]
* Git tutorial [http://socialledge.com/sjsu/index.php/Basic_Git_Tutorial]
* Unit-test reference [https://gitlab.com/sibros_public/public/-/wikis/c/unit_tests#lab-1]
* Getting started with SJ-Two [https://sjsu-dev2.readthedocs.io/en/latest/getting_started/getting_started/]

===Motor Controller===
* Traxxas User Manual: [https://images-na.ssl-images-amazon.com/images/I/D1NTpa7RNES.pdf]
* Traxxas Specification Sheet: [https://images-na.ssl-images-amazon.com/images/I/81WphBAuwIL.pdf]

===Geological Controller===
* Movable Scripts (Calculate distance, bearing and more between Latitude/Longitude points): [https://www.movable-type.co.uk/scripts/latlong.html]
* CMPS11 (I2C Configuration): [https://www.robot-electronics.co.uk/htm/cmps11i2c.htm]

===Bridge and Sensor Controller===
* [https://www.slamtec.com/en/Lidar/A1 LIDAR]
* [https://components101.com/ultrasonic-sensor-working-pinout-datasheet Ultrasonic sensor ]
===Driver and LCD Controller===
* LCD Software: [https://4dsystems.com.au/ulcd-32ptu 4Dsystems]
===Android===
* Youtube Channel: [https://www.youtube.com/channel/UCoNZZLhPuuRteu02rh7bzsw Coding with Mitch]
* Android Developers: [https://developer.android.com/guide/topics/connectivity/bluetooth Website][https://github.com/googlearchive/android-BluetoothChat Github]
* Udemy Course: [https://www.udemy.com/course/the-complete-android-oreo-developer-course/ Complete Android Oreo Developer Course]
===PCB Design===
* Design Tool: [https://easyeda.com/ EasyEDA]

S20: Canster Truck

2020-05-23T06:40:00Z

Proj user22: /* GLCD UI */

[[File:CMPE243_S20_T2_Canster_Truck_Logo.png|thumb|455px|caption|right|CAN-STER TRUCK LOGO]]

== '''Abstract''' ==
The Canster Truck Project is an autonomous RC car with CAN Bus interfaced controllers. The development of the RC car's subsystem modules (Interfacing of Ultrasonic Sensor, LIDAR, Bluetooth, GPS, Compass and CAN modules) was divided among six team members. The aim of the project is to develop an autonomous RC Car which can navigate from one source location to the selected destination on the app by avoiding obstacles in its path using sensors. Waypoints algorithm is used as the path finding technique.
 

== '''Introduction and Objectives''' ==

'''The project was divided into 7 modules:'''

* '''Bridge and Sensor Controller'''
* '''Motor Controller'''
* '''Geological Controller'''
* '''Driver and LCD Controller'''
* '''Hardware Integration'''
* '''Android Application'''
* '''Testing & Code Review'''

'''RC Car Objectives'''
'''1. Driver and LCD Controller''' - Handles algorithms for obstacle avoidance, route maneuvering, and waypoints
'''2. Geological Controller''' - Recieves coordinates from GPS and Heading from Compass for navigation
'''3. Motor Controller''' - Controls movements of the RC Car
'''4. Bridge and Sensor Controller''' - Detects surrounding objects and interfaces android application to controller via bluetooth
'''Team Objectives'''

[[File:CMPE243_S20_T2_High_Level_System_Diagram.png|thumb|center|800px| High Level System Diagram]]

 

== '''Team Members and Responsibilities''' ==
[[File:CMPE243_S20_T2_Canster Truck_Team.jpg|thumb|center|800px| Group Picture]]

'''Gitlab Project Link''' - [https://gitlab.com/coder137/can-ster_truck '''Canster Truck''']
 

*'''Niket Naidu''' [https://www.linkedin.com/in/niket-naidu-30090a134/ LinkedIn] [https://gitlab.com/coder137 Gitlab]
** '''Geological Controller''' : GPS, Compass, Waypoint Algorithm, Haversine and Bearing Angle logic
** '''Driver and LCD Controller''' : GLCD
** '''Bridge and Sensor Controller''' : Bluetooth
** '''Testing & Code Review'''

*'''Ganesh Ram Pamadi''' [https://www.linkedin.com/in/ganeshram93/ LinkedIn] [https://gitlab.com/ganeshram2493 Gitlab]
** '''Hardware Integration'''
** '''Testing & Code Review'''
** '''Driver Controller'''
** '''Motor Controller'''

*'''Nikhil Pabbisetty''' [https://www.linkedin.com/in/nikhilpabbisetty/ LinkedIn] [https://gitlab.com/nikhilpeoria Gitlab]
** '''Bridge and Sensor Controller'''
** '''Motor Controller'''
** '''Driver and LCD Controller'''
** '''Hardware Integration'''

*'''Akhil Cherukuri''' [https://www.linkedin.com/in/akhilcherukuri/ LinkedIn] [https://gitlab.com/akhilcherukuri Gitlab] [https://github.com/akhilcherukuri Github]
** '''Android Application'''
** '''Bridge and Sensor Controller'''

*'''Ashish Anant Ladage''' [https://www.linkedin.com/in/ashish-anant-ladage-7bb3a214b/ LinkedIn] [https://gitlab.com/ashishladage1 Gitlab]
** '''Driver and LCD Controller'''
** '''Hardware Integration'''
** '''Motor Controller'''

*'''Jesus De Haro De Reza''' [https://www.linkedin.com/in/jesus-de-haro-66342424/ LinkedIn] [https://gitlab.com/deharo27 Gitlab]
** '''Bridge and Sensor Controller'''
** '''Motor Controller'''

 

== '''Administrative Responsibilities''' ==
* '''Team Lead''' - [https://www.linkedin.com/in/niket-naidu-30090a134/ '''Niket Naidu''']
* '''Git Repository Manager''' - [https://www.linkedin.com/in/niket-naidu-30090a134/ '''Niket Naidu''']
* '''Bill Of Materials Manager''' - [https://www.linkedin.com/in/akhilcherukuri '''Akhil Cherukuri''']
* '''Wiki Report Manager''' - [https://www.linkedin.com/in/akhilcherukuri '''Akhil Cherukuri''']

 

== '''Schedule''' ==

{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-

! scope="row"| '''1'''
| style="text-align:center;" |'''02/11/2020'''
| style="text-align:center;" |'''02/17/2020'''
|
*'''Form teams and decide group name'''
*'''Review past projects'''
*'''Slack: Create project group and invite Preet'''
*'''GitLab: Create project groups repository'''
*'''Analysis of component required'''

|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''2'''
| style="text-align:center;" |'''02/18/2020'''
| style="text-align:center;" |'''02/24/2020'''
|
*'''Study CAN Communication'''
*'''Create Bill of Materials'''
*'''Order RC Car'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''3'''
| style="text-align:center;" |'''02/25/2020'''
| style="text-align:center;" |'''03/02/2020'''
|
*'''Setup team finance management using Splitwise application'''
*'''Complete Bill of Materials'''
*'''Order all other required components'''
*'''Wikipedia: Setup project report template'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''4'''
| style="text-align:center;" |'''03/03/2020'''
| style="text-align:center;" |'''03/09/2020'''
|
*'''Read the respective datasheets and manuals for each component'''
*'''Test each component for working conditions'''
|
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''5'''
| style="text-align:center;" |'''03/10/2020'''
| style="text-align:center;" |'''03/16/2020'''
|
*'''Assign team responsibilities and roles'''
*'''Setup team project management environment (ClickUp)'''
*'''Define CAN DBC'''
*'''Research GPS antennas and order'''
*'''Android: Environmental setup of Android Studio and enable version control'''
*'''Hardware : Decide PCB editing software (easyEDA)'''
*'''Hardware : Draft schematic for required PCB design'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''6'''
| style="text-align:center;" |'''03/17/2020'''
| style="text-align:center;" |'''03/23/2020'''
|
*'''Hardware : Create model of PCB''' 
*'''Android: Add a Button for changing bluetooth connection status in the application''' 
*'''Geological: Interface Compass module with SJ-2 board using I2C interface''' 
*'''Geological: Interface GPS module with SJ-2 board using the UART interface''' 
*'''Geological: Parse raw data to get meaningful values for GPS and Compass''' 
*'''Sensor: Interface and check the functionality of ultrasonic sensors to the SJ-2 board''' 
*'''Motor: Interface of Servo & DC motor to the SJ-2 board and check for basic functionality''' 
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''7'''
| style="text-align:center;" |'''03/24/2020'''
| style="text-align:center;" |'''03/30/2020'''
|
*'''Hardware : Finalize components placement on PCB.''' 
*'''Motor: Add PWM functionality and test the code on DC and servo motors''' 
*'''Sensor: Interface and check and study the output readings of Lidar sensor with SJ-2 board over UART''' 
*'''LCD Display: Explore UI designing of LCD''' 
*'''Hardware: Finalize on optimal ultrasonic sensor placements''' 
*'''Android: Initiate Bluetooth communication and show staus via text view''' 
*'''Wikipedia: Establish final wiki schedule'''
*'''Complete CAN communication format for each controller and link DBC file to the Wiki'''
*'''Complete high-level system block diagram'''
*'''Complete unit-level block diagrams'''
*'''Bridge: Interface HC-5 bluetooth module with Sj-2 board using serial communicaton'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''8'''
| style="text-align:center;" |'''03/31/2020'''
| style="text-align:center;" |'''04/06/2020'''
|
*'''Hardware: Analyze PCB model and order PCB Circuit board''' 
*'''Android: Initiate Bluetooth communication and send "Hello World".''' 
*'''Wikipedia: Start adding information/images/diagrams to the relevant sections'''
*'''Motor: Configure ESC for correct speed outcome according to frequency & PWM values''' 
*'''Motor: Finish RPM sensor hardware and software implementation and integration''' 
*'''Sensor: Read output from Lidar and setup structure for outputting for DBC''' 
*'''Geological: Implement waypoints algorithm''' 
*'''Driver: Implement obstacle avoidance algorithm''' 
*'''Bridge: Pass data such as "Hello World" from HC-05 bluetooth module to bluetooth terminal android application'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''9'''
| style="text-align:center;" |'''04/07/2020'''
| style="text-align:center;" |'''04/13/2020'''
|
*'''Hardware: Remove Unused parts from RC Car''' 
*'''Hardware: Mount PCB and 3D Parts''' 
*'''Motor: Decide different cut-off values from sensor to command right /slight right/ straight/ slight left/ left to motor.''' 
*'''Android: Embed Google Maps API for setting the car's destination.''' 
*'''LCD: Work to show RC cars live status information(battery level, current speed, long, lat, bearing, sensor data, etc)''' 
*'''Driver: Test obstacle avoidance algorithm and fine-tune sensor readings''' 
*'''Geological: Test checkpoint algorithm''' 
*'''Bridge: Establish two way communication between android application and bluetooth module''' 
*'''Update Bill of Materials for miscellaneous hardware'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''10'''
| style="text-align:center;" |'''04/14/2020'''
| style="text-align:center;" |'''04/20/2020'''
|
*'''Hardware: Integrate all hardware modules''' 
*'''LCD: Testing & Validation of the LCD UI and display vehicle status information''' 
*'''Android: Send car location to the app and checkpoints received to Geo module''' 
*'''Motor: Optimize PID control by accelerating/decelerating as instructed by Driver''' 
*'''Bridge: Configure HC-05 for auto reconnection if bluetooth communication disconnects''' 
*'''Add multiple debug messages and transmit on CAN'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''11'''
| style="text-align:center;" |'''04/21/2020'''
| style="text-align:center;" |'''04/27/2020'''
|
*'''Android: Send additional vehicle status information from RC car to the Application for display''' 
*'''Android: Finalize User Interface Design and Icon''' 
*'''Continuously test the whole system and handling of corner cases (outside).'''
*'''Finalize RC Car For Project Proto 1'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''12'''
| style="text-align:center;" |'''04/28/2020'''
| style="text-align:center;" |'''05/04/2020'''
|
*'''Gitlab: Push final code'''
*April 28th: Project Proto 1
*'''Finalize RC Car for Project Demo'''
*May 1st: Project Presentation
*'''Finalize RC Car for Project Proto 2'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''13'''
| style="text-align:center;" |'''05/05/2020'''
| style="text-align:center;" |'''05/21/2020'''
|
* '''Complete Individual Contribution Peer Grading'''
* '''Review and Complete Wiki Project Page'''
|
*'''Completed'''
*'''Completed'''
|-
|}

 

== '''Bill Of Materials''' ==
{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Item#
! scope="col"| Part Description
! scope="col"| Part Model & Vendor
! scope="col"| Quantity
! scope="col"| Cost in USD
|-
! scope="row"| 1
| '''Microcontroller Boards'''
| SJ2 Boards (Purchased from Preet Kang)
| 4
| $200.00
|-
! scope="row"| 2
| '''CAN Transceivers'''
| [https://www.waveshare.com/sn65hvd230-can-board.htm Waveshare SN65HVD230]
| 12
| $54.48
|-
! scope="row"| 3
| '''RC Car'''
| [https://www.amazon.com/Traxxas-Slash-Course-2-4GHZ-Vehicle/dp/B01DU474B0/ref=sr_1_3?ie=UTF8&qid=1474747759&sr=8-3&keywords=Traxxas+1%2F10+slash+2wd Traxxas 2WD RTR with 2.4Ghz Radio]
| 1
| $260.00
|-
! scope="row"| 4
| '''Lithium-Ion Battery'''
| [https://www.rcsuperstore.com/traxxas-7600mah-2s-7-4v-25c-id-lipo-battery-pack/ Traxxas 7600mAh 2S 7.4V 25C iD LiPo Battery Pack]
| 1
| $75.00
|-
! scope="row"| 5
| '''Lithium-Ion Battery Charger'''
| [https://www.amazon.com/Traxxas-2970-EZ-Peak-Charger-Identification/dp/B00OAFYLJC/ref=pd_bxgy_21_img_2?ie=UTF8&psc=1&refRID=JVX791WVV9Y8T9DW92KW Traxxas 2970 EZ-Peak Plus 4-Amp NiMH/LiPo Fast Charger]
| 1
| $50.00
|-
! scope="row"| 6
| '''Compass Breakout Board'''
| [https://www.dfrobot.com/product-1275.html DFRobot CMPS11 Compass]
| 1
| $29.99
|-
! scope="row"| 7
| '''Bluetooth Breakout Board'''
| [https://www.amazon.com/HC-05-Bluetooth-Pass-through-Wireless-Communication/dp/B01G9KSAF6/ref=sr_1_4?ie=UTF8&qid=1507077325&sr=8-4&keywords=arduino+bluetooth+hc-05 DSD TECH Bluetooth HC-05]
| 1
| $8.49
|-
! scope="row"| 8
| '''LIDAR Sensor'''
| [https://www.amazon.com/RPLiDAR-A1M8-Degree-Laser-Scanner/dp/B07H7X3SFF/ref=sr_1_fkmrnull_1?crid=2FSUI76G4UA8K&keywords=rplidar+a1m8+-+360+degree+laser+scanner+development+kit&qid=1552764172&s=gateway&sprefix=RPlidar%2Caps%2C263&sr=8-1-fkmrnull SEEED STUDIO RPLIDAR A1M8]
| 1
| $109.99
|-
! scope="row"| 9
| '''RPM Sensor'''
| [https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM Traxxas 6520 RPM Sensor]
| 1
| $13.70
|-
! scope="row"| 10
| '''GPS Breakout Board'''
| [https://www.adafruit.com/product/746 Adafruit Ultimate GPS Breakout v3]
| 1
| $44.30
|-
! scope="row"| 11
| '''LCD Display'''
| [https://4dsystems.com.au/ulcd-32ptu 4Dsystems 3.2 TFT-LCD ULCD-32PTU]
| 1
| $79.00
|-
! scope="row"| 12
| '''Ultrasonic Sensors'''
| [https://www.amazon.com/gp/product/B01COSN7O6/ ELEGOO HC-SR04 Ultrasonic Module]
| 5
| $12.00
|-
! scope="row"| 13
| '''GPS Antenna'''
| [https://www.amazon.com/dp/B07RRT615K/ GPS Antenna A1-UX]
| 1
| $10.98
|-
! scope="row"| 14
| '''PCB Fabrication'''
| [https://jlcpcb.com/ JLCPCB]
| 5
| $40.15
|-
! scope="row"| 15
| '''Miscellaneous'''
| [https://www.amazon.com Amazon],[https://www.mouser.com/ Mouser Electronics],[https://www.digikey.com/ Digikey],[https://anchor-electronics.com/ Anchor Electronics]
| ~
| $48.07
|-
! scope="row"|
|
|
| '''Total'''
| '''$1036.15'''
|-

|}

 

== '''Printed Circuit Board''' ==

=== Design And Architecture ===
The complete PCB (for boards and hardware peripherals) was designed using EasyEDA online software. The 4 nodes will be communicating via CAN bus and other peripherals are connected to the PCB via headers.

=== Power Section===
We have 2 power banks supplying our system. And the Servo Motor, RPM sensor and DC rear Motor (via ESC) are powered using LiPo battery (6 volts).
* Power bank #1 - Subset 2

* Power bank #2 - Subset 1, Subset 3, Bluetooth Module

'''NOTE:'''

'''Subset 1:'''
1. LIDAR
2. LCD
3. Compass

'''Subset 2:'''
1. Motor node
2. Driver node
3. BS node

'''Subset 3:'''
1. Geo node
2. Back ultrasonic sensor

=== Fabrication ===
* PCB was sent to fabrication to JLCPCB China which provided PCB with MOQ of 5 and 2 layers of PCB and common grounded the rest of the copper area.
'''DRC elements (in mils)'''
* Track Width = 12
* Clearance = 10
* Via Diameter = 24
* Via Drill Diameter = 12

=== Challenges ===
* Auto-routing gave lot of challenges (only ~60% success) and sometimes the online server even crashes and faces downtime. Even local routing had lot of issues. So make sure to plan your design accordingly.
* We started our PCB design well ahead of the project. So lot of pre-planning had to be done with regard to final hardware and placement of components in order to avoid spending extra time and money while re-ordering.
* The PCB went through a lot of internal revisions even before placing order. This was time-consuming.

'''Other hardware challenges:'''
* Figuring out why various hardware peripherals (GPS, Bluetooth, LIDAR and Ultrasonic sensor) started to malfunction (devices were on but values were either inconsistent / not occurring), took a lot of time to debug. It was due to insufficient power.

 
[[File:CMPE243 S20 T2 EasyEDA.png|1040x1200px|thumb|center|PCB Layout Design in EasyEDA]]
 
[[File:CMPE243 S20 T2 PCB SCHEMATIC.jpg|1041x550px|thumb|center|PCB Schematic]]
 
[[File:CMPE243 S20 T2 PCBFRONT.jpg|thumb|center|600px|PCB Top Layer]]
 
[[File:CMPE243 S20 T2 PCBBACK.jpg|thumb|center|600px|PCB Bottom Layer]]

 

== '''CAN Communication''' ==

=== Hardware Design ===
[[File:CMPE243_S20_T2_Canster_Truck_CANHW.png|thumb|center|770px| CAN Hardware Diagram]]

=== DBC File ===

DBC FILE: [https://gitlab.com/coder137/can-ster_truck/-/blob/dbc-improvements/projects/lpc40xx_freertos/project.dbc Gitlab]

<pre>
VERSION ""

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

BS_:

BU_: DBG DRIVER IO MOTOR SENSOR GEO

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" GEO,MOTOR,SENSOR

BO_ 101 GEO_HEARTBEAT: 1 GEO
SG_ GEO_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,MOTOR,SENSOR

BO_ 102 MOTOR_HEARTBEAT: 1 MOTOR
SG_ MOTOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,SENSOR

BO_ 103 SENSOR_HEARTBEAT: 1 SENSOR
SG_ SENSOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,MOTOR

BO_ 200 MOTOR_STEERING: 1 DRIVER
SG_ MOTOR_STEERING_direction: 0|8@1- (1,0) [-2|2] "" MOTOR

BO_ 210 DRIVER_COORDINATES: 8 DRIVER
SG_ DRIVER_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
SG_ DRIVER_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 220 MOTOR_SPEED: 1 DRIVER
SG_ MOTOR_SPEED_processed: 0|8@1- (1,0) [-3|3] "" MOTOR

BO_ 300 GEO_DEGREE: 8 GEO
SG_ GEO_DEGREE_current: 0|32@1+ (0.000001,0) [0|360] "degrees" DRIVER
SG_ GEO_DEGREE_required: 32|32@1+ (0.000001,0) [0|360] "degrees" DRIVER

BO_ 310 GEO_DESTINATION_REACHED: 1 GEO
SG_ GEO_DESTINATION_REACHED_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 400 MOTOR_SPEED_FEEDBACK: 4 MOTOR
SG_ MOTOR_SPEED_current: 0|32@1+ (0.1,0) [0|60] "kph" DRIVER

BO_ 500 SENSOR_BT_COORDINATES: 8 SENSOR
SG_ SENSOR_BT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
SG_ SENSOR_BT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 510 SENSOR_SONARS: 8 SENSOR
SG_ SENSOR_SONARS_left: 0|21@1+ (0.001,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right: 21|21@1+ (0.001,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle: 42|21@1+ (0.001,0) [0|0] "cm" DRIVER

BO_ 520 SENSOR_LIDAR: 8 SENSOR
SG_ SENSOR_LIDAR_middle: 0|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_slight_left: 16|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_slight_right: 32|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_back: 48|16@1+ (1,0) [0|0] "cm" DRIVER

BO_ 530 MOTOR_KEY: 1 SENSOR
SG_ MOTOR_KEY_val: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 900 GEO_CURRENT_COORDINATES: 8 GEO
SG_ GEO_CURRENT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" DBG
SG_ GEO_CURRENT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" DBG

BO_ 901 GEO_DISTANCE_FROM_DESTINATION: 4 GEO
SG_ GEO_distance_from_destination: 0|32@1+ (0.001,0) [0|0] "meters" DBG

BO_ 902 MOTOR_INFO_DBG: 4 MOTOR
SG_ MOTOR_INFO_DBG_rps: 0|16@1+ (1,0) [0|0] "" DBG
SG_ MOTOR_INFO_DBG_pwm: 16|16@1+ (0.001,0) [0|0] "" DBG

BO_ 903 LIPO_BATTERY_VOLTAGE_DBG: 4 MOTOR
SG_ LIPO_BATTERY_VOLTAGE_val: 0|32@1+ (0.01,0) [0|0] "volts" DBG

BO_ 904 CURRENT_CHECKPOINT_DBG: 1 GEO
SG_ CURRENT_CHECKPOINT_val: 0|8@1+ (1,0) [0|0] "" DBG

CM_ "--BU (Network Node) Information--";
CM_ BU_ DRIVER "The driver controller of the car";
CM_ BU_ GEO "The geo controller of the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";

CM_ "--BO (Message) Information--";
CM_ BO_ 100 "Driver Sync message used to synchronize the controllers";
CM_ BO_ 101 "Geo Sync message used to synchronize the controllers";
CM_ BO_ 102 "Motor Sync message used to synchronize the controllers";
CM_ BO_ 103 "Sensor Sync message used to synchronize the controllers";

CM_ BO_ 200 "Steering direction values sent by Driver Node to Motor Node";
CM_ BO_ 210 "Driver Destination coordinates sent by Driver Node";
CM_ BO_ 220 "Required motor speed computed from Driver Node to Motor Node";

CM_ BO_ 300 "Current and computer/required degree values sent by Geo Node";
CM_ BO_ 310 "Indicator signal to check if the RC car has reached the destination";

CM_ BO_ 400 "Current motor info (rps and kph) sent as feedback to the Driver Node";

CM_ BO_ 500 "Coordinate BT values (destination coordinates) sent by Sensor Node";
CM_ BO_ 510 "LIDAR - Distance from obstacle detected in each sector";
CM_ BO_ 520 "Ultrasonic Sensor - Distance from obstacle detected by each sensor";
CM_ BO_ 530 "Start/Stop signal from the Bluetooth app";

CM_ BO_ 900 "Destination coordinates for BUSMASTER debugging";
CM_ BO_ 901 "Distance from destination";
CM_ BO_ 902 "Supplied PWM value to the motor and its RPM";
CM_ BO_ 903 "LIPO Battery Voltage";
CM_ BO_ 904 "Current checkpoint of the car";

CM_ "--SG (Signal) Information for Heartbeats--";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver node";
CM_ SG_ 101 GEO_HEARTBEAT_cmd "Heartbeat command from the geological node";
CM_ SG_ 102 MOTOR_HEARTBEAT_cmd "Heartbeat command from the motor node";
CM_ SG_ 103 SENSOR_HEARTBEAT_cmd "Heartbeat command from the sensor node";

CM_ "--SG (Signal) Information for DRIVER Node--";
CM_ SG_ 200 DRIVER_STEERING_direction "Calculated Driver Steering values (-2,2) for Motor";
CM_ SG_ 210 DRIVER_COORDINATES_latitude "Destination Latitude coordinate";
CM_ SG_ 210 DRIVER_COORDINATES_longitude "Destination Longitude coordinate";
CM_ SG_ 220 MOTOR_SPEED "Calculated Driver speed values (-3,3) for Motor";

CM_ "--SG (Signal) Information for GEO Node--";
CM_ SG_ 300 GEO_DEGREE_current "Current Geo Degree relative to true north";
CM_ SG_ 300 GEO_DEGREE_required "Calculated Geo Degree computed by Haversine Formula";
CM_ SG_ 310 GEO_DESTINATION_REACHED "Indicator signal to check if the RC car has reached the destination";

CM_ "--SG (Signal) Information for MOTOR Node--";
CM_ SG_ 400 MOTOR_SPEED_FEEDBACK "Feedback speed (kph) sent by Motor Node";

CM_ "--SG (Signal) Information for SENSOR Node--";
CM_ SG_ 500 SENSOR_BT_COORDINATES_latitude "Destination Latitude received over Bluetooth";
CM_ SG_ 500 SENSOR_BT_COORDINATES_longitude "Destination Longitude received over Bluetooth";
CM_ SG_ 510 SENSOR_SONARS_left "Ultrasonic Sensor attached to the left side";
CM_ SG_ 510 SENSOR_SONARS_right "Ultrasonic Sensor attached to the right side";
CM_ SG_ 510 SENSOR_SONARS_middle "Ultrasonic Sensor attached to the middle";
CM_ SG_ 510 SENSOR_SONARS_back_left "Ultrasonic Sensor attached to the back left side";
CM_ SG_ 510 SENSOR_SONARS_back_right "Ultrasonic Sensor attached to the back right side";
CM_ SG_ 520 SENSOR_LIDAR_middle "Lidar sensing the middle sector (-15 to 15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_left "Lidar sensing the slight left sector (-45 to -15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_right "Lidar sensing the slight right sector (15 to 45 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_back "Lidar sensing the back of the car (165 to 195 degrees)";
CM_ SG_ 530 MOTOR_KEY_val "1 -> Start the motor from the app, 0 -> Stop";

CM_ SG_ 900 GEO_CURRENT_COORDINATES_latitude "Current Latitude";
CM_ SG_ 900 GEO_CURRENT_COORDINATES_longitude "Current Longitude";
CM_ SG_ 901 GEO_distance_from_destination "Distance from destination";
CM_ SG_ 902 MOTOR_INFO_DBG_rps "Current RPS value of the motor";
CM_ SG_ 902 MOTOR_INFO_DBG_pwm "Supplied motor PWM value";
CM_ SG_ 903 LIPO_BATTERY_VOLTAGE_val "LIPO Battery Voltage";
CM_ SG_ 904 CURRENT_CHECKPOINT_val "Current checkpoint of the car";

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

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

BA_ "GenMsgCycleTime" BO_ 100 1000;
BA_ "GenMsgCycleTime" BO_ 200 50;
BA_ "FieldType" SG_ 100 DRIVER_HEARTBEAT_cmd "DRIVER_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 102 GEO_HEARTBEAT_cmd "GEO_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 103 MOTOR_HEARTBEAT_cmd "MOTOR_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 104 SENSOR_HEARTBEAT_cmd "SENSOR_HEARTBEAT_cmd";

BA_ "FieldType" SG_ 200 MOTOR_STEERING "MOTOR_STEERING";
BA_ "FieldType" SG_ 230 MOTOR_SPEED_val "MOTOR_SPEED_val";
BA_ "FieldType" SG_ 310 GEO_DESTINATION_REACHED_cmd "GEO_DESTINATION_REACHED_cmd";

VAL_ 100 DRIVER_HEARTBEAT_cmd 2 "DRIVER_HEARTBEAT_cmd_REBOOT" 1 "DRIVER_HEARTBEAT_cmd_SYNC" 0 "DRIVER_HEARTBEAT_cmd_NOOP" ;
VAL_ 101 GEO_HEARTBEAT_cmd 2 "GEO_HEARTBEAT_cmd_REBOOT" 1 "GEO_HEARTBEAT_cmd_SYNC" 0 "GEO_HEARTBEAT_cmd_NOOP";
VAL_ 102 MOTOR_HEARTBEAT_cmd 20 "MOTOR_HEARTBEAT_cmd_REBOOT" 10 "MOTOR_HEARTBEAT_cmd_SYNC" 0 "MOTOR_HEARTBEAT_cmd_NOOP" ;
VAL_ 103 SENSOR_HEARTBEAT_cmd 200 "SENSOR_HEARTBEAT_cmd_REBOOT" 100 "SENSOR_HEARTBEAT_cmd_SYNC" 0 "SENSOR_HEARTBEAT_cmd_NOOP" ;

VAL_ 200 MOTOR_STEERING_direction -2 "MOTOR_STEERING_hard_left" -1 "MOTOR_STEERING_slight_left" 0 "MOTOR_STEERING_straight" 1 "MOTOR_STEERING_slight_right" 2 "MOTOR_STEERING_hard_right";
VAL_ 220 MOTOR_SPEED_processed -3 "MOTOR_SPEED_reverse_fast" -2 "MOTOR_SPEED_reverse_medium" -1 "MOTOR_SPEED_reverse_slow" 0 "MOTOR_SPEED_neutral" 1 "MOTOR_SPEED_forward_slow" 2 "MOTOR_SPEED_forward_medium" 3 "MOTOR_SPEED_forward_fast";
VAL_ 310 GEO_DESTINATION_REACHED_cmd 1 "GEO_DESTINATION_REACHED_cmd_REACHED" 0 "GEO_DESTINATION_REACHED_cmd_NOT_REACHED";
</pre>

 

== '''Motor Controller''' ==
'''[https://gitlab.com/coder137/can-ster_truck/-/tree/motor_bleeding_edge_dev GitLab Link]'''

This controller is used to control the components of the car-related to motor. We can control the speed and steering of the car having interfaced with various components with the SJ-2 board. The servo motor is controlled via PWM and is used to set the steering direction of the car. The DC motor is controlled by the Electronic Speed Controller (ESC) via PWM for speed. We read the speed of the car by using an RPM sensor. By using the RPM sensor values, a feedback loop has been designed to regulate the speed of the car. A state machine has been designed to manage the forward and backward movements of the car.
Additionally, a voltage divider circuit has been implemented to read the battery voltage. All motor functionality and CAN message communication is run at 10 Hz.

=== Hardware Design ===

[[File:CMPE243_S20_T2_Canster_Truck_Motor_Hardware.png|thumb|center|750px| Motor Hardware System]]

The following diagram details the hardware implementation of the motor module with the SJTwo board:
Hardware Interface
=====Servo Motor=====
The servo motor responds to PWM pulses. It has three pins namely Vcc, PWM Input Signal, and GND. The servo is powered using 6V from the car battery. Based on the PWM signal supplied from the SJTwo board the front wheels are turned.
[[File:CMPE243_S20_T2_Canster_Truck_Motor_1.jpg|440px|thumb|center|| Servo Motor]]
{| class="wikitable" style="text-align: center; width: 400px; height: 200px; margin: left;"
|+ Servo Motor Pin Connection
|-
! Sr. No.
! Wires - Servo Motor
! Function
|-
! 1
| PWM Connected to P2.5 || PWM Signal from Sj-2 Board
|-
! 2
| VCC || 6V supply from ESC
|-
! 3
| GND || Common Ground
|-
|}

=====Electronic Speed Controller (ESC)=====
The ESC is used to control the DC motor. It is supplied power using the 7.4 V LiPo battery. It has three pins namely Vout, PWM Input Signal, and GND. Based on the PWM input signal, the speed and forward, neutral, and backward movements of the car is changed. Vout is given to the RPM sensor and Servo motor.
[[File:CMPE243_S20_T2_Canster_Truck_Motor_2.jpg|440px|thumb|center|| Electronic Speed Controller (ESC)]]
{| class="wikitable" style="text-align: center; width: 400px; height: 200px; margin: left;"
|+ Speed Sensor Pin Connection
|-
! Sr. No.
! Wires - RPM Sensor
! Function
|-
! 1
| Signal Wire Connected to P2.0 || GPIO that supplies pulses to controller
|-
! 2
| VCC || 6V supply from ESC
|-
! 3
| GND || Common Ground
|-
|}

=====DC Motor=====
The DC motor is controlled using the ESC. It has two pins, a positive and a negative terminal. A PWM signal wire is connected to the microcontroller and the required current is provided by the LiPo battery and the ESC. The DC motor is controlled using PWM at 10Hz.

[[File:CMPE243_S20_T2_Canster_Truck_Motor_3.jpg|320px|thumb|center|| DC Motor]]
{|
|-
|
{| class="wikitable" style="text-align: center; width: 400px; height: 200px; margin-left:0px;"
|+ DC Motor Pin Connection
|-
! Sr. No.
! Wires - DC Motor
! Description
|-
! 1
| Positive Wire (already connected) || Positive Terminal
|-
! 2
| Negative Wire (already connected || Negative Terminal
|-
|}
 
{| class="wikitable" style="text-align: center; width: 400px; height: 200px;"
|+ DC Motor Configuration
|-
! Operation
! Pulse Width Range (ms)
! Duty Cycle(%)
|-
! FORWARD
| 1.51 - 2.00 || 15.1-20.0
|-
! STOP
| 1.50 || 15.0
|-
! REVERSE
| 1.00 - 1.49 || 10.0-14.9
|-
|}
|
|-
|}

Note: First calibrate the DC motor or the motor will not respond to your PWM pulses. For help with calibration go to this [https://traxxas.com/support/Programming-Your-Traxxas-Electronic-Speed-Control website]

=====RPM Sensor=====

The RPM sensor is used to get the current speed of the car. We use the info for creating a feedback loop (PID) for maintaining the speed of the car in uphill and downhill situations. The RPM sensor mounts on the rear DC motor shaft compartment with a special assembly also provided by Traxxas. The magnet which attached to the inner gear generates a pulse each rotation. The sensor works on the hall effect principle where it provides a current across its terminal when placed in a magnet's field. The RPM sensor has three pins namely Vcc, Signal, and GND.

[[File:CMPE243_S20_T2_Canster_Truck_Motor_4.jpg|440px|thumb|center|| RPM Sensor]]

{| class="wikitable" style="text-align: center; width: 400px; height: 200px; margin: left;"
|+ Speed Sensor Pin Connection
|-
! Sr. No.
! Wires - RPM Sensor
! Function
|-
! 1
| Signal Wire Connected to P2.2 || GPIO that supplies pulses to controller
|-
! 2
| VCC || 6V supply from ESC
|-
! 3
| GND || Common Ground
|-
|}

=== Software Design ===

The software for the motor node was divided into multiple files and made modular to improve readability and understanding of the complex logic involved. The main code modules are for:
*Servo Motor
*Electronic Speed Controller
*RPM Sensor
*Motor Wrapper
*Battery Voltage

The motor wrapper module is used to wrap all the code from the esc, servo, and rpm modules into simple to use functions to be called in the periodic tasks.
=====Servo Motor=====
It uses the steering value sent from the driver (-2 to 2) and matches it to the appropriate PWM value for steering. This code module is run at 10Hz.
<pre>
void servo__steer_processor(int16_t steering_value) {
switch (steering_value) {
case MOTOR_STEERING_hard_left:
servo__steer_hard_left();
break;
case MOTOR_STEERING_slight_left:
servo__steer_soft_left();
break;
case MOTOR_STEERING_straight:
servo__steer_straight();
break;
case MOTOR_STEERING_slight_right:
servo__steer_soft_right();
break;
case MOTOR_STEERING_hard_right:
servo__steer_hard_right();
break;
default:
printf("\nDid not receive steering value");
}
}
</pre>
=====Electronic Speed Controller=====

This code module is used to control the DC motor. It receives the motor direction value from the driver and sets the appropriate PWM value. Based on the value the motor is commanded to move the car forward or backwards. A switch case is implemented to set PWM values for movement in different directions along with different speeds.
<pre>
void esc__direction_processor(int16_t direction_value) {
desired_direction_value = direction_value;
switch (direction_value) {
case MOTOR_SPEED_reverse_fast:
esc__reverse_fast();
break;
case MOTOR_SPEED_reverse_medium:
esc__reverse_medium();
break;
case MOTOR_SPEED_reverse_slow:
esc__reverse_slow();
break;
case MOTOR_SPEED_neutral:
esc__neutral();
break;
case MOTOR_SPEED_forward_slow:
esc__forward_slow();
break;
case MOTOR_SPEED_forward_medium:
esc__forward_medium();
break;
case MOTOR_SPEED_forward_fast:
esc__forward_fast();
break;

default:
printf("\nDid not receive direction and speed value");
}
}
</pre>

There is also a feedback loop to control the speed. The ESC code depends on the rpm sensor code for the current speed values.
<pre>
double current_speed = get_speed_kph();
double desired_speed = desired_speed_kph;
float adjusted_duty_cycle = 0.0;
adjusted_duty_cycle = duty_cycle + (speed_to_pwm_adjustment(desired_speed, current_speed));
</pre>

[[File:CMPE243_S20_T2_Canster_Truck_Motor1.png|thumb|center|500px| Feedback Loop for Motor Speed]]

=====RPM Sensor=====
This code module is used to get current speed data from the RPM sensor. It is based on interrupts. When the wheel rotates once, we get one pulse due to the magnet installed. This pulse generates a falling edge interrupt during which we increment the pulse counter. Since, this code is run at 1Hz we collect the number of pulses generated every one second. This gives us the number of rotations per second using which we can calculate the speed in kph.
<pre>
float rpm__calculate_speed_kph() {
uint16_t rotation_per_sec = pulse_count;
pulse_count = 0;
speed_kph = ((CIRCUMFERENCE_METER * rotation_per_sec) * (MPS_TO_KPH_CONVERSION_FACTOR)) / GEAR_RATIO;
return speed_kph;
}
</pre>

=====Motor Wrapper=====
As mentioned above, the main function of this code module is to wrap all the other code modules and call the right functions at the appropriate frequency. The motor wrapper code also includes a state machine for ensuring a smooth transition between forward to backward state and vice versa. In order to achieve a smooth transition, a series of PWM pulses must be generated at the right time. For example, when the motor is moving from forward to backward state, a reverse value must be given first followed by at least three neutral values, and then continue with reverse values.

[[File:CMPE243_S20_T2_Canster_Truck_Motor2.png|thumb|center|500px| State Machine Flowchart for Motor Movements]]

=====LiPo Battery Voltage=====

The LiPo Battery Voltage was calculated using ADC in Burst Mode. A LiPo Hardware module was created for the same which contained two functions, <code>lipo__init</code> and <code>lipo__get_voltage</code>.

The voltage divider circuit is stepped down from 7.4V to 2.1V using 10K and 4K Resistor pair.
[[File:CMPE243_S20_T2_Canster Truck_Motor_Voltage_Regulator.png|thumb|center|400px| Voltage Regulator]]
'''LiPo Initialization'''

The LiPo Initialization phase initializes the ADC, Enables Burst mode on the ADC pins and configures the Alternate Function Registers for the same.

'''Getting LiPo Voltage'''

We read the raw ADC value from the LPC Hardware register. This value will be from 0 - 3.3V. However due to our voltage divider configuration the max voltage that we should theoretically get is 2.1V. This means that 2.1V corresponds to 7.4V of the LIPO Battery voltage.

The formula used is
<code>(raw_adc_value * MAX_LIPO_BATTERY_VOLTAGE_VALUE) / MAX_LIPO_ADC_VALUE</code>

=== Technical Challenges ===
<li>Changing movements of the car from Forward to Backward and vice versa
If you just change the PWM value from say 16 (Forward) to 14(Backward), the DC motor will just stop and will not make wheels turn reverse. We discovered this problem quite late as during the initial testing we had always run the car from the start with either forward or reverse but never tried changing the direction during run-time.
 
Solution: The motor requires a series of PWM pulses which is specific to the car to transition from forward mode to reverse mode. In our case we had to give the PWM pulses in the following sequence. Suppose,
<ol>
<li> Forward (16) (callback_count = 0)</li>
<li> Forward (16) (callback_count = 1)</li>
<li> Reverse (14) (callback_count = 2)</li>
<li> Neutral (15) (callback_count = 3)</li>
<li> Neutral (15) (callback_count = 4)</li>
<li> Neutral (15) (callback_count = 5)</li>
<li> Reverse (14) (callback_count = 6)</li>
<li> Continue reverse</li>
</ol>
Similarly, the reverse to forward can also be implemented.
<li>DC motor shooting off when there is an improper ground connection
When we connected the battery voltage circuit for reading the voltage from the battery, the motor would randomly shoot off every now and then.
 
Solution: Connect the voltage divider circuit to the common ground rather than taking the ground from the ESC.</li>

 

== '''Geological Controller''' ==
'''[https://gitlab.com/coder137/can-ster_truck/-/tree/geo_bleeding_edge_dev_waypoints GitLab Link]'''

===Messages===
*GEO_HEARTBEAT: Used to check for MIA by other nodes. Highest priority message for GEO Node

*GEO_DEGREE: Sends the current degree relative to the North Pole computed by the Compass and the Required degree relative to the North Pole computed by Bearing Angle using the Current Coordinate and Destination Coordinate.

*GEO_DESTINATION_REACHED: Sets a flag, 0 for destination not reached and 1 for destination reached

*GEO_CURRENT_COORDINATES: Debug Message used to send the Current GPS Coordinates

*GEO_DISTANCE_FROM_DESTINATION: Debug message used to send the Distance from Destination

*CURRENT_CHECKPOINT_DBG: Debug message used to check which checkpoint is being navigated to

=== Hardware Design ===

[[File:CMPE243_S20_T2_GEO1.png|thumb|center|650px| Geological Diagram]]

=== Software Design ===
=====Overview=====
*Inside the `periodic_callback__initialize`
**Initialize the CAN BUS
**Initialize the GPS

*Inside the `periodic_callback__1hz`
**Handle all MIA (from other Nodes)
**Update GPS LED when init and in case of failure
**Compute the GEO logic for Waypoints algorithm once every second (1000 ms)

*Inside the `periodic_callback__10hz`
**Handle CAN Incoming messages (Decode)
**Transmit CAN Geo messages (Encode and send)
**Compute the GPS Coordinate

=====Compass I2C Driver=====
An online datasheet resource was used to work with the Compass ([https://www.robot-electronics.co.uk/htm/cmps11i2c.htm CMPS11 Datasheet])
Initially the Compass I2C Driver was tested using the Terminal I2C Helper built by our Professor Preetpal Kang. Using this resource we were quickly able to read various I2C Registers and display it onto the terminal.

For our project the only required part of the Compass was the 16-bit Compass Bearing value (0-3599) i.e 0-359.9 degree values. These values were stored in the 2nd and 3rd register (Register 2 being the High Byte).
Once the raw data was received over I2C we could easily combine the data

<pre>
uint16_t bearing_value = (Reg2 << 8) | Reg3;
float rval = bearing_value / 10.0;
return rval;
</pre>
The returned value were transmitted to the Driver Node to compute its steering based on the required Bearing Angle.

=====GPS Initialization=====
GPS Initialization activates the Hardware GPIO (RX and TX), FreeRTOS Queue for UART Interrupts (UART Module) and Line Buffer Module to parse each GPS line.

=====GPS Data Parsing=====
The GPS Hardware module transmits an NMEA string over UART to the SJTwo Board. We read each character one by one and add it to the Line Buffer module.
Inside its computation loop, the Line Buffer module checks if a newline character has been received.
When a newline character has been received the entire string is extracted from the line buffer module and parsed according to its identifier ($GPRMC, $GPGGA) received and parsed into individual tokens.
For our purposes the $GPRMC NMEA string was the most appropriate and it helped us extract the Current Latitude Longitude as well as the Valid/Invalid tag for the Canster Truck.

=====GPS LED Indication for debugging=====

A simple module that checks for the GPRMC GPS Message and extracts the A or V valid (Tag). If $GPRMC NMEA string is valid, LED is set, else LED is reset. This gives us onsite debugging capabilities to know if GPS has locked onto a satellite signal.

=====GEO Logic Module Computation=====
The GEO Logic Module computes the Bearing Angle, Haversine Distance as well as the Waypoints algorithm.

'''Bearing Angle:'''

<code>
θ = atan2( sin Δλ ⋅ cos φ2 , cos φ1 ⋅ sin φ2 − sin φ1 ⋅ cos φ2 ⋅ cos Δλ )
</code>

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

Since atan2 returns values in the range -π ... +π (that is, -180° ... +180°), to normalize the result to a compass bearing (in the range 0° ... 360°, with −ve values transformed into the range 180° ... 360°), convert to degrees and then use (θ+360) % 360, where % is (floating point) modulo.
For final bearing, simply take the initial bearing from the endpoint to the start point and reverse it (using θ = (θ+180) % 360).

The above article reference gives us the required bearing angle that our car must align itself to, to reach a particular destination coordinate from its current coordinate.
The Steering of the vehicle depends on the above-computed angle values.

'''Haversine Distance Formula:'''

This uses the ‘haversine’ formula to calculate the great-circle distance between two points – that is, the shortest distance over the earth’s surface – giving an ‘as-the-crow-flies’ distance between the points (ignoring any hills they fly over, of course!).

<code>
a = sin²(Δφ/2) + cos φ1 ⋅ cos φ2 ⋅ sin²(Δλ/2)

c = 2 ⋅ atan2( √a, √(1−a) )

d = R ⋅ c
</code>

where φ is latitude, λ is longitude, R is earth’s radius (mean radius = 6,371km);
note that angles need to be in radians to pass to trig functions!

The above formula is used to calculate the distance between the source coordinate (received via GPS) and the destination coordinate.
Later this was used to compute the distance between source coordinate and each individual checkpoint to traverse the shortest distance.

'''Waypoints Algorithm:'''

The Waypoints algorithm that was chosen was a slightly modified version of Djikstra’s Algorithm.
3 values were calculated before the final computation

* Distance between source and final destination (DISTsd)
* Distance between source and each individual checkpoint (DISTsc)
* Distance between each individual checkpoint and the final destination. (DISTcd)

If '''DISTsd''' was lesser than '''DISTcd''', this checkpoint was discarded (we continue in the loop). Since we would be moving in the opposite direction, rather than towards the final destination.

If '''DISTsd''' was greater than '''DISTcd''', then we checked the nearest checkpoint to the source.
The minimum value was set initial that was equal to '''DISTsd'''.

If '''DISTsc''' was lesser than the minimum value stored, '''DISTsc''' would become the new minimum value, and the checkpoint index and coordinates would be appropriately stored and returned from the function.

In this way we would navigate to the nearest checkpoint from the source, while also making sure NOT to travel in the opposite direction.
This logic is recomputed only when we reach the checkpoint selected and the algorithm runs again to find the next checkpoint that we need to navigate to.

=====CAN Decode Destination Coordinates=====
Destination Coordinates are received from the Bridge and Sensor Node and transmitted over the CAN Bus. The value is decoded and stored in the GEO Logic Module.
This is a very important value since our entire GEO Logic calculations are based on the Destination Coordinate.

=====CAN Encode and Send=====

The main messages that were transmitter are
#Geo Degree
#Geo Destination Reached
#Distance from Destination Debug and Checkpoint Index debug

'''Geo Degree Computation as per Waypoints Algorithm:'''

Geo Degree was computed as per the current coordinates and the most recently computed checkpoint coordinates. This bearing angle calculation w.r.t computed checkpoint would continue till we do not reach that particular checkpoint.
Once we reach the computed checkpoint, Waypoint algorithm is recomputed as per the process mentioned above and the algorithm runs again.

'''Geo Destination Reached:'''

An Area of around 4 meters was set around the destination coordinate to check if the destination had been reached.
This measurement was taken into consideration to allow for the loss in precision when transmitting data over CAN as well as any irregularities that might occur when getting values from the GPS.
Having an area of 4 meters was very accurate for all of our test runs.

'''Geo Distance from Destination Debug and Checkpoint Index Debug:'''

Getting debug information was very critical to speed up our development process. In this case we could actively see if our algorithm worked properly.
The Geo Distance from Destination was used to see if we were moving closer to our destination or veering further away from it.
The Checkpoint Index was used to see which checkpoint index we were traveling to. By knowing the placements of the Individual checkpoints we could manually as well as programmatically (via Android application) verify the working of our Canster Truck.

=== Technical Challenges ===
#DBC Challenge for GEO Coordinates -> Could not encode more than 5-6 decimal places at a time, on later investigation we found that the 10000 is an int value, however 100000 overflows the int value.
#Creating an efficient algorithm for Waypoints, O(n) complexity.
#Getting appropriate fixes for GPS when not in a completely open space.
#GPS used to fluctuate or stop giving values when Battery voltage went below a particular threshold. Always supply 3.3V constantly at a good amperage.

 

== '''Sensor [Bridge and Sensor Controller]''' ==
'''[https://gitlab.com/coder137/can-ster_truck/-/tree/sensor_bleeding_edge_dev GitLab]'''
==='''Ultrasonic Sensor'''===
====Hardware Design====
This sensor uses an ultrasonic beam to measure the distances. Based on the time taken between when the beam is sent and received back to the sensor, the distance is calculated in the node.
Apart from 5v and GND, this sensor has 2 pins ECHO and TRIG which are interfaced with the SJ-Two board via GPIO.

[[File:CMPE243_S20_T2_CansterTruck_ultrasonic_sensor.jpg|thumb|center|300px| Ultrasonic Sensor Diagram]]

====Software Design====
* Init the GPIO pin connected to TRIG of the sensor as output and for ECHO as an input port.
* Attach the interrupt on the ECHO input port.
* Store the system_clock_count before setting the trigger pulse and then set the pulse. Also keep monitoring the input port.
* Take the system_clock_count at the instant of receiving the interrupt.
Distance = (system_clock_count_at_trig - system_clock_count_after_at_echo) / 57.14

==='''Lidar Sensor'''===
====Hardware Design====
The RPLidar sensor can be powered from a 5v source and uses UART communication to receive commands and transmit data. It has seven pins to interface with. Two sets of the pins (four total) are for power and ground. The remaining three are for UART receive and transmit, and for making the lidar’s motor spin.

[[File:CMPE243_S20_T2_Canster_Truck_RPLidar_A1.JPG|thumb|center|300px| RPLidar A1]]

====Software Design====
In terms of the lidar, the SJ2 initializes GPIO, UART, and memory for storing the measurement values. After initialization, the command to begin scanning is sent. Here, we wait for the lidar to send a response packet, letting the host (SJ2 board) know it received the command. The response packet the lidar sends will be 7 bytes. If the correct 7 bytes are not received, the command will be sent again.

[[File:CMPE243_S20_T2_Canster Truck_Lidar_flow.jpeg|thumb|center|200px| Lidar Flow]]

Following the response packet, the lidar begins sending 5-byte measurement data. Each sample contains a distance measurement (in millimeters) and the angle (with respect to the lidar) in which it was taken. The data packet structure is shown in the following figure. In addition to containing the distance and angle, the packet includes a quality value, to indicate the reliability of the measurement, and three check bits (S, ~S, and C). As the data is received via UART, we wait until we have 5 bytes before continuing to process. Before processing the 5 bytes after receiving them, the check bits are confirmed to be correct. If they are incorrect, it will not be processed and we will wait for another sample to be received.

[[File:CMPE243_S20_T2_Canster Truck_DataPacketStructure.JPG|thumb|center|200px| Data Packet Structure]]

In the case the sample is correct, each measurement value that is in a direction of interest will be placed in an array designated to one of four directions (left, right, front, rear). Each of these directions have their own sector in the lidar’s 360-degree view.
*Right sector: 11° - 30°
*Rear sector: 170° - 190°
*Left sector: 330° - 349°
*Front sector: 350° - 370° (or 10°)

The arrays mentioned will hold roughly 20 measurements, which are every degree in the sector. In the event, objects are too far to measure, the lidar will report 0 mm. distance. Since there is no measurable obstacle, a “large” distance value of 3000 mm. is placed in the array. The smallest distance value will be taken from each array and reported to the driver node for obstacle avoidance.

=== Technical Challenges ===
====Ultrasonic Sensor====
*'''Power issue''' The pulses were getting triggered incorrectly and it took a while to figure out that it was due to insufficient power.

====LIDAR====
*'''Datasheet not 100% clear:''' The correct datasheet for the was a bit difficult to obtain, and the manufacturer needed to be contacted. The first document found online was high level and general information about the sensor, but the manufacturer did provide another document that contained the information of the commands and responses to and from the lidar, and their packet structure. The documents did not clearly state the angles with respect to the lidar are fixed, which left me wondering if the lidar will think the direction it is facing when powered on will become the new “zeroth” angle.

*'''UART Buffer Overflow:''' When first interfacing with the sensor, the incoming bytes of the lidar were printed on to the terminal to make sure there was a response and to make sense of the information. Since the command we sent results in 5 bytes of data per measurement samples from the lidar and the lidar measured 2000 times per second, there are will be roughly 10k Bytes per second of data incoming that need to be handled continuously. With an improperly sized UART buffer and print statements it is guaranteed to occur, making the lidar data look like random values.

*'''Proper Parsing of Measurement Data:''' After sending a command to the lidar, the sensor will send a response packet, followed by the measurement data. The initial response from the lidar is a 7-byte packet, followed by continuous 5-byte measurement samples. I needed to make sure however I handled the response would be independent of how the measurement is handled, so as not to create a potential unwanted offset when receiving measurements.

*'''Object Detection with Received Data:''' Once proper communication was set up with the lidar and measurement data was getting decoded, there needed to be a way to measure when obstacles were present. If ~360 measurements are handled entirely independently from one another, it could become a complex and confusing code. To achieve a simple approach, four sectors about 20 degrees in size were used to represent the front, left, right, and rear directions.

*'''Bugs in Code:''' When first implementing the code, there were a few bugs from typos, incorrect numbers, and some faulty logic that were found with the use of unit testing. Unit testing helped find these issues and verified the logic was correct, and I would say gave me 90% confidence in my lidar handling.

 

== '''Bluetooth Module [Bridge and Sensor Controller]'''==

Bridge functionality of the Bridge and Sensor Controller is to establish wireless communication between the SJ-2 Board and the android mobile device using the HC-05 Bluetooth module. The Bridge controller will be receiving start command with destination GEO coordinates and stop command. The Bridge controller will be transmitting the required sensor data and debug information to be displayed on the android application.

[[File:CMPE243_S20_T2_BRIDGE.png|thumb|center|500px| Bridge Diagram]]

==== Software Design ====

'''Low-Level Layer'''

In this layer, similar to the GPS the UART GPIO was initialized (RX, TX), FreeRTOS Queue was initialized for UART Interrupts and the line buffer module was initialized to parse strings.

Two basic functions <code>bt__read</code> and <code>bt__write</code> were implemented.
As the name suggested, <code>bt__write</code> took a string as its input parameter and transmitted that data to the Android application. <code>bt__read</code> stored the incoming characters into the line buffer, parsed the line received into its identifier and tokens, and invoked a callback function.

Since this was a low-level layer the User would not be directly invoking this library. Instead a '''Bluetooth Wrapper''' module was created which would be invoked and used by the user.

'''Application Layer'''

The Bluetooth Wrapper module had the appropriate <code>read_once</code> and <code>write_once</code> functions.

The <code>read_once</code> function internally just called the <code>bt__read</code> function. All of the decodings was done inside the Callback Function.
To get the Destination coordinate the string received from the Android Application was in the form of
<code>$loc,<destination_latitude>,<destination_longitude>.</code>
Upon receiving this data we parsed the destination_latitude and destination_longitude, which could later be accessed using getters.
We also set a start flag to notify the Driver Node that destination has been received and we can start steering towards our checkpoints.

Another command implemented was the stop command.
<code>$stop</code>
This was used to send a stop flag to the Driver node.

The <code>write_once</code> function used the getter methods from each CAN Decode message and update its internal state variables. A CSV String was created using the <code>$canster</code> identifier and various debugging points were appended to this message using a comma.
On the Android application side this CSV string was tokenized and displayed onto the Application Debug screen appropriately.

==== Technical Challenges ====

'''Bluetooth peripheral not turning on'''
* We initially connected the Bluetooth module directly to the SJ-Two board with (Vcc = 3.3v). But it was not giving only 2.7v and hence the device did not turn on.
* We had to connect it to external power source to make it function without hassles.

 

== '''Driver [Driver and LCD Controller]''' ==
'''[https://gitlab.com/coder137/can-ster_truck/-/tree/driver_bleeding_edge_dev GitLab]'''

=== Software Design ===

[[File:CMPE243_S20_T2_Canster Truck_Driver_Flowchart.png|thumb|center|750px|Driver Flowchart]]

The above block diagram explains the process flow of obstacle detection for the car. The LIDAR detects
the obstacle and depending on the distance of obstacle the car takes a slight right and slight left or a
hard right and hard left. The state of the car also depends on the value of the LIDAR and ultrasonic sensor.
The loose ends of the LIDAR for the reverse condition are checked by the ultrasonic sensors. The
The ultrasonic sensor works on the principle of trigger and echo and can detect the obstacles very close by.
The range of the Ultrasonic sensor is lower than the LIDAR. Finally, if no obstacle is detected the car goes
straight until the destination is reached. The speed of the car is also various when an obstacle is detected to
avoid the crash and the car’s smooth transition from one state to another. The key to the android
application controls the start and stop the process of the car. If the key is not pressed, then the stays in the

neutral state. The speed of the car is controlled by the changing duty cycle of the input voltage. There
are seven-speed levels in which the motor can run on. These speed levels are Forward Slow, Medium,
Fast, Reverse Slow, Medium, Fast, and Neutral. The Neutral is the stop condition with a 0% duty cycle.

=== Technical Challenges ===

Technical Challenges faced during obstacle detection:

*Due to dimensions of the car and for the perfect obstacle avoidance the values of 100cm and 150cm had to be selected for the turning radius. Hence, it is very important to calibrate these values appropriately, as these values will be unique for different car designs.
*For a situation, where even if the lidar doesn’t detect any obstacle at the middle, the car must take a slight right or a slight left as per our design. This is the case where the obstacle can be a moving one and that is why the lidar middle couldn’t detect it.

 

== '''LCD [Driver and LCD Controller]''' ==
=== Hardware Design ===
[[File:CMPE243_S20_T2_Canster_Truck_LCD_Diagram.png|thumb|600px|center| LCD Design]]
{|style="text-align: center; width: 400px; height: 200px; margin: auto;"
|
[[File:CMPE243_S20_T2_Canster_Truck_GLCD.jpg|thumb|200px|center| GLCD Hardware]]
||
[[File:CMPE243_S20_T2_Canster_Truck_GLCD2.jpg|thumb|600px|center| GLCD Software Simulation]]
|
|}

=== Software Design ===
The GLCD used was created by 4DSystems, using their IDE a UI was created. Each UI component could be controlled by sending UART data targeted at the widget address.
The best part about this GLCD was that we had a lot of interactive widgets to display debugging information in real-time.
The GLCD code was divided into 3 parts:

=====Low-Level Initialization=====
Initialize the low-level hardware interfaces to send and receive data from the GLCD.
Similar to the GPS and Bluetooth, The UART GPIO was initialized (RX, TX), FreeRTOS Queue was initialized for UART Interrupt and line buffer was used to get a stream of data for parsing.

Low-level '''read''' and '''write''' commands were used as per the working of the GLCD Module.
When Reading data pertaining to a widget on the GLCD we would need to send a particular response packet.

<pre>
void lcd__read(lcd_object_e object_id, uint8_t object_index, uint8_t *response, uint16_t *response_data) {

uint8_t checksum = READ_OBJ ^ object_id ^ object_index;
uint8_t buffer[] = {READ_OBJ, object_id, object_index, checksum};

lcd__write_data(buffer, sizeof(buffer) / sizeof(uint8_t));
lcd__read_response_id(response);
lcd__read_response_data(response_data);
}
</pre>

The response_data returned contains the Widget ID as well as the current value stored on that widget.

When Writing data pertaining to a widget on a GLCD the process is similar to the above mentioned code.
<pre>
void lcd__write(lcd_object_e object_id, uint8_t object_index, uint8_t msb, uint8_t lsb, uint8_t *response) {
uint8_t checksum = WRITE_OBJ ^ object_id ^ object_index ^ msb ^ lsb;
uint8_t buffer[] = {WRITE_OBJ, object_id, object_index, msb, lsb, checksum};

lcd__write_data(buffer, sizeof(buffer) / sizeof(uint8_t));
lcd__read_response_id(response);
}
</pre>

However in this case we receive only an ACK or NACK from the system. ACK would mean that the write to GLCD widget was successful and the widget now stored appropriate values. NACK would mean that a particular error has occurred. The errors could be regarding baud rate, incorrect bit format, incorrect index values, etc.

=====GLCD Wrapper for Widgets=====
The above low-level code had generic read and write functions. However for our UI we were only using 3 Widgets. All of which had '''different Indexes''' and '''Widget IDs'''.
Therefore a very simple library was created to easily interface with those widgets
<pre>
bool lcd_wrapper__read_led(uint8_t index);
uint16_t lcd_wrapper__read_meter(uint8_t index);
uint16_t lcd_wrapper__read_leddigit(uint8_t index);

bool lcd_wrapper__write_led(uint8_t index, bool value);
bool lcd_wrapper__write_meter(uint8_t index, uint16_t value);
bool lcd_wrapper__write_leddigit(uint8_t index, uint16_t value);
</pre>

The above code is self-explanatory read and write functions for '''LED''', '''METER''', and '''LED DIGIT'''.

=====GLCD UI=====
Now that we had our low level and Widget wrapper working properly, we wanted to create our Dynamic UI as well. The code would need to be robust enough to handle any UI that we create on the GLCD which could be reflected equivalently in our C Code.

<pre>
static void lcd_ui__update_ui(void) {

lcd_wrapper__write_led(LCD_LED_DRIVER_MIA_INDEX, driver_mia_led);
lcd_wrapper__write_led(LCD_LED_SENSOR_MIA_INDEX, sensor_mia_led);
lcd_wrapper__write_led(LCD_LED_GEO_MIA_INDEX, geo_mia_led);
lcd_wrapper__write_led(LCD_LED_MOTOR_MIA_INDEX, motor_mia_led);

// kph is always in the range of 0 - 10
lcd_wrapper__write_meter(LCD_METER_KPH_INDEX, kph_meter % 11);

// These will be in the Range of 0-99
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_RPM_INDEX, rpm_leddigit % 100);
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_CURRENTDEGREE_INDEX, cdegree_leddigit % 100);
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_REQUIREDDEGREE_INDEX, rdegree_leddigit % 100);
}
</pre>

As we can see the <code>lcd_ui__update_ui</code> function was called periodically inside the 1Hz function. It updated the screen in real time based on the static values that were stored AND updated inside the LCD UI module.
The Constant INDEX values stored were directly mapped onto the Index values were received from the 4DWorkshop UI Software.

=== Technical Challenges ===

*The GLCD needs to be supplied appropriate voltage (5V) at 1A for it to work properly. The LCD does not turn on without an appropriate power supply
*The GLCD UART interface has an additional RES signal. This RES signal resets the GLCD when pulled low. When connecting the UART display it is recommended to always reset the GLCD display for proper working
*The GLCD has a latency of up to 30ms when querying and receiving data. In our case, the real-time system has hard caps on time (i.e up to 1second of delay is possible on the 1Hz function)
*This was rectified by putting the read functions (if any) inside the low priority 1Hz periodic_callback function.
*Write operations do not suffer from such a latency issue since they only send one byte (ACK or NACK) signal back.
*Fortunately most of our logic involved just a write (setting a value on the GLCD) rather than reading or querying the widget.

 

== '''Android Application''' ==
[https://gitlab.com/akhilcherukuri/can-ster_truck_application Gitlab]
=== Software Design ===

<div><ul>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android4.jpg|thumb|none|220px|Info Activity (Top)]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android7.jpg|thumb|none|220px|Info Activity (Middle)]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android5.jpg|thumb|none|220px|Info Activity (Bottom)]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android6.jpg |thumb|none|220px|Debug Activity Screen]]</li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster_Truck_Android_GIF1.gif|thumb|center|220px|App Animations]]</li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster_Truck_Android_GIF2.gif|thumb|center|220px|Live Location]]</li>
</ul></div>
The application consists of a total of 5 Activities:

=====Main Activity=====
**This is the app launch display screen
**It will check for all the required permission onStart().
**Has search button for connecting from a paired device list view
**Once device is clicked, an intent will start the Map Activity
=====Map Activity=====
* For this requirement we are using the Google Maps Fragment, for the map fragment to function we must request an API key from Google and set the key in the manifest of the application.
* Destination marker(Red Marker) is set using <code>setOnMapClickListener</code> to which the car will navigate to, the destination can be changed by clicking elsewhere on the Map Fragment. The marker can be removed using <code>setOnMarkerClickListener</code>.
* When the start button is pressed, the start command identifier along with destination latitude and longitude is sent to the car via the write thread. A background thread is started along with it to indicate the current car's position(Green Marker) along with a plotline between the current position and destination.
* When the stop button is pressed, the stop command identifier is sent to the car, to stop and turn off the car.
=====Info Activity=====
* Messages from Geological, Driver, Motor coming from CAN bus are decoded by the Sensor and Bridge controller and sent to the Android application as a string.
* The received string is parsed and categorizes the data to store it in the required textView to be displayed.
* Bluetooth status, Lidar Values, Ultrasonic Sensor Values, Motor Speed, Motor RPM, Motor PWM, Cars' current location, Compass Heading, Distance till Destination, Checkpoint Index is displayed. This was useful for debugging purposes and allowed us to avoid scanning the mounted LCD or CAN Busmaster on PC during drives.
=====Debug Activity=====
*The main function of this activity is to check all RAW RX and RAW TX messages and create a log of all the data received and sent.
=====Bluetooth Connection Service Activity=====
*This is the background activity that handles all the threads required for transmission and receiving data using Bluetooth connections. It has 3 running threads which is called inside other activities using a handler:
* Accept Thread - Listens to BluetoothServerSocket using listenUsingRfcommWithServiceRecord. In order for the RF communication socket to connect to the HC-05, we used the following <code>UUID: 00001101-0000-1000-8000-00805F9B34FB</code>. This is a generic SSP Bluetooth UUID that enables the socket to directly connected to HC-05 and maintain the connection.
* Connect Thread - Creates a Bluetooth socket using createRfcommSocketToServiceRecord
* Connected Thread - Creates socket.getInputStream(); and socket.getOutputStream(); when bytes are available in input stream it will read them into a buffer.
**All messages for activities are done by <code> Handler mHandler.obtainMessage(); mHandler.sendMessage(); </code>

'''Receieved string:'''
* A String is sent to the Bluetooth app from HC-05 and when it receives a string with identifier "$canster", the message is prased accordingly by using the string delimiter ',' and is ended by the newline character '\n' which will remove the data from StringBuffer.
* <code>Example: $canster,37.339334,-121.881123,37.338713,-121.880685,10.123,20.133,30.123,10.5,88.1,99.2,-2,1,44,7,11,22,33,-3,23\n</code>

'''Manifest:'''
<pre>
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.INTERNET" />
</pre>

'''Dependencies:'''
<pre>
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'com.google.android.gms:play-services-maps:17.0.0'
compile 'com.google.maps.android:android-maps-utils:0.4+'
implementation 'androidx.cardview:cardview:1.0.0'
implementation 'com.google.android.gms:play-services-location:17.0.0'
implementation 'androidx.appcompat:appcompat:1.1.0'
implementation 'androidx.constraintlayout:constraintlayout:1.1.3'
implementation 'com.android.support:design:28.0.0'
implementation 'androidx.navigation:navigation-fragment:2.2.1'
implementation 'androidx.navigation:navigation-ui:2.2.1'
implementation 'androidx.lifecycle:lifecycle-extensions:2.2.0'
</pre>

[[File:CMPE243_S20_T2_BLUETOOTHFLOWCHART.png|thumb|center|650px| Android Application Flowchart]]

=== Technical Challenges ===
*'''Bluetooth Discovery:''' While creating the android application, we were not able to see any Bluetooth devices in the paired device list. The problem was that for the Android versions above Lillipop we would also need location access. We have solved it by writing a function to check whether to check for permissions or not.
<pre>
private void checkBluetoothPermissions() {
Log.d(TAG, "checkBTPermissions: Checking permissions");
int permission_check = this.checkSelfPermission("Manifest.permission.ACCESS_FINE_LOCATION");
permission_check += this.checkSelfPermission("Manifest.permission.ACCESS_COARSE_LOCATION");
if (permission_check != 0) {
this.requestPermissions(new String[]{Manifest.permission.ACCESS_FINE_LOCATION, Manifest.permission.ACCESS_COARSE_LOCATION}, 1001); //Any number
}
else{
Log.d(TAG, "checkBTPermissions: No need to check permissions. SDK version < LOLLIPOP.");
}
}
</pre>
*'''Catching NULL in a StringTokenizer: ''' When sending data using Bluetooth sometimes thee app crashes. Using debug Run log in Android Studio IDE, we have found out that this is because we get <code> NullPointerException, java.util.StringTokenizer </code> error. This is mainly due to passing a null value to the StringTokenizer constructor. This problem can be avoided by after reading a line from the Bluetooth StringBuffer, we check whether it is null, before passing it to the StringTokenizer, but later on, we have preferred to use <code>split();</code> to prase the received string as StringTokenizer is now a legacy class that is retained for compatibility reasons and its use is discouraged in new code.

*'''XML Layouts: ''' Generating layouts is difficult for new android code developers, the design layouts made should be compatible for a wide range of mobile devices but using the new android libraries we have found that, the older phones then tend to have difficulty in showing the layouts correctly. We have solved this problem by learning the design commercial XML design layouts by following tutorials on Udemy and Youtube.

*'''Auto Connect''': During the first stages we have implemented Bluetooth connection via searching for all devices and clicking on the device from Listpair to connect. This has a lot of time to process all the discovered devices near range. To solve this we have hardcoded the HC-05 device address <code>00:14:03:06:02:83</code> to <code>mBluetoothAdapter.getRemoteDevice("device address")</code>.

 

== '''Management''' ==
===Git Management===

Git Management amongst 6 team members was definitely a very challenging task. Depending on our initial design we could’ve had a lot of merge conflicts. However those risks were mitigated by spending a LOT of time in the initial stages to decide our pipeline and structure.

<li>There are certain components in our system that were COMMON. For example the CAN initialization, communication and decodes were all similar for the most part between all the 4 Controllers. The utility modules used were also similar in nature</li>
<li>Thus we made a common branch that contained the templates for CAN Nodes (not Controllers), Hardware code and Utility functions.
<ol>
<li>Later this common branch was forked into an individual Controller specific branch (SENSOR, GEO, MOTOR or DRIVER).</li>
<li>Only the Logic folder contained Controller specific code, specific to that controller.</li>
</ol>
<li>This gave us a lot of flexibility since all the team members had similar APIs to work with on all 4 branches. This promoted easy understanding and learning.
<ol>
<li>Many team members frequently worked on 2 or more controllers at a time where can messages were concerned. Having a APIs also meant that just the can_handler needed to be updated regularly followed by the equivalent logic code. </li>
<li>Inside the logic folder, getters to the can node modules were frequently used.</li></ol>

An example of how one of our initial templates was setup.
<pre>
├───can_module
│ ├───can_bus_initializer
│ ├───can_constants
│ ├───can_driver_node
│ ├───can_geo_node
│ ├───can_handler
│ ├───can_motor_node
│ ├───can_sensor_node
│ └───test
├───hardware
│ ├───bt
│ ├───compass
│ ├───gps
│ ├───lcd
│ ├───lidar
│ ├───motor
│ ├───test
│ └───ultrasonic
├───logic
│ ├───driver_obstacle
│ ├───driver_state
│ ├───geo_logic
│ └───test
└───utility
├───line_buffer
└───test
</pre>

'''Challenges'''
<li>It was initially a bit of a learning curve to understand the flow of the repository</li>
<li>When using a git management system with different versions in each branch it became very tough when the number of branches suddenly exploded in size. A lot of relevant code was stuck in a lot of different branches.
<ol>
<li>This happened mainly due to assignment submissions and unclosed MRs that eventually became stale.</li>
<li>Our strategy was to abandon these MRs and keep forking from these branches without merging it back into its final controller branch.</li>
<li>The latest branches that were kept were aptly named `<controller>_bleeding_edge_dev` branches since they were never merged back from where they were forked.</li>
</ol>
<li>Since a lot of our code also depended on the DBC autogenerated code, we could not suddenly change the DBC Message names once they were established since it caused a change in the Struct name that was generated and used.
<ol>
<li>Our solution to this was to keep everything backward compatible. We added new function names without deleting old DBC messages.</li>
<li>In certain places where we wanted to modify a function name it was done one by one so that a lot of the code is not broken at one time.</li>
</ol>
<li>Common Branches eventually became stale as our progress continued on the bleeding edge branches
<ol>
<li>For example certain GPS features needed to be added which were done on the GEO_bleeding_edge_dev branch but never pushed or cherry-picked back into the COMMON branch.</li>
<li>This was a similar issue to our 2nd point but manageable since the goal of the COMMON branch was to provide a template for further work and nothing more.</li>
<li>At the end of the day each controller is its own Individual Project and while the messages between them are same. The Hardware code does not need to be same.</li>
<li>This also prompted team-members to ask if we could delete unused hardware or logic file code (which wasn’t being used and was imported from the template). This was also fine and can be done during cleanup stage. However we eventually got used to the Modular system of our project so much so that we did not worry about the additional modules that were present in each branched controller project.</li>
</ol>

 

== '''Conclusion''' ==
CMPE243 gives one of the best experiences one could ever get in their academic life. The course is designed to give an insight into how the industry functions and enhances both technical and management skills. Apart from learning how to work and implement application of CAN protocol, one can get a hands-on experience with version control, unit-testing and software design. Overall it was a very great and memorable journey.

=== Project Video ===

=== Project Source Code ===
* [https://gitlab.com/coder137/can-ster_truck GitLab Link]

=== Advise for Future Students ===
'''GENERAL:'''
* Form your team and start the project as early as you can.
* Clearly discuss what role each individual should do and ensure that progress is regularly tracked so that the team doesn't fall back on any schedule.
* Make sure your early structure of the project is decided. Before you start to write the code make sure that all the team and code guidelines are discussed. In our case we spent most of our first week deciding how we wanted to structure and design our code. This paid off in the long run since we had robust code inside one repository that could be extended efficiently.
* Make sure each module is individually testable i.e through periodic callbacks as well as unit-tests. While unit-tests can help for a lot of situations and provide a robust way to map the working of the module, it cannot simulate certain real-life scenarios. For example, Lidar buffer was constantly getting full due to the large number of incoming bytes. This caused us to have certain incorrect reading appear after a few minutes of the lidar running. Our solution was to minimize the <code>printf</code> statements inside the module that were used for debugging.
* Since lot of code and hardware integration is involved with this project, make sure testing is thoroughly and periodically done and make note of all the issues found.
'''HARDWARE:'''
* Decide on how you would power up the peripherals. We had issues with Bluetooth (not connecting), GPS (lock not happening) and LIDAR (giving incorrect values). After lot of cycles of hardware and software debugging, we found that the issue was with power. Choose wisely as to which peripherals must be connected to which power source.
* Isolate the power hungry devices to other parallel connections so that the voltage drop is not high. In our case the Graphical LCD and LIDAR were both very power hungry peripherals. The LCD used to start glitching incase there was a large voltage drop and the LIDAR used to give incorrect values or not update correctly. We solved this issue by giving the lidar a dedicated power supply.
* PCB design involves lot of hardware components. Coordinating with multiple team members and verifying each hardware connection takes quite some time. So start well ahead.
* Make sure to expose some extra GPIO and GND pins for future use.
'''MOTOR:'''
* You can use the LiPo battery to power the RPM and servo motor instead of using a separate power source. Use Vout from the ESC to get 6V.
* Start the PID control calibration early on as you will need to do extensive testing to get it working.

=== Acknowledgement ===
<HR>
Firstly we would like to express our gratitude to Professor Preetpal Kang for his guidance throughout the semester and providing us with this opportunity. We would also like to thank the ISA members Vignesh Kumar Venkateshwar and Aakash Vrajlal Chitroda for being available whenever in need and guiding us to complete the project.

== '''References''' ==
* CAN Reference [https://www.kvaser.com/about-can/can-dictionary/]
* FreeRTOS Reference [http://socialledge.com/sjsu/index.php/FreeRTOS_Tutorial]
* Git tutorial [http://socialledge.com/sjsu/index.php/Basic_Git_Tutorial]
* Unit-test reference [https://gitlab.com/sibros_public/public/-/wikis/c/unit_tests#lab-1]
* Getting started with SJ-Two [https://sjsu-dev2.readthedocs.io/en/latest/getting_started/getting_started/]

===Motor Controller===
* Traxxas User Manual: [https://images-na.ssl-images-amazon.com/images/I/D1NTpa7RNES.pdf]
* Traxxas Specification Sheet: [https://images-na.ssl-images-amazon.com/images/I/81WphBAuwIL.pdf]

===Geological Controller===
* Movable Scripts (Calculate distance, bearing and more between Latitude/Longitude points): [https://www.movable-type.co.uk/scripts/latlong.html]
* CMPS11 (I2C Configuration): [https://www.robot-electronics.co.uk/htm/cmps11i2c.htm]

===Bridge and Sensor Controller===
* [https://www.slamtec.com/en/Lidar/A1 LIDAR]
* [https://components101.com/ultrasonic-sensor-working-pinout-datasheet Ultrasonic sensor ]
===Driver and LCD Controller===
* LCD Software: [https://4dsystems.com.au/ulcd-32ptu 4Dsystems]
===Android===
* Youtube Channel: [https://www.youtube.com/channel/UCoNZZLhPuuRteu02rh7bzsw Coding with Mitch]
* Android Developers: [https://developer.android.com/guide/topics/connectivity/bluetooth Website][https://github.com/googlearchive/android-BluetoothChat Github]
* Udemy Course: [https://www.udemy.com/course/the-complete-android-oreo-developer-course/ Complete Android Oreo Developer Course]
===PCB Design===
* Design Tool: [https://easyeda.com/ EasyEDA]

S20: Canster Truck

2020-05-23T06:37:46Z

Proj user22: /* Git Management */

[[File:CMPE243_S20_T2_Canster_Truck_Logo.png|thumb|455px|caption|right|CAN-STER TRUCK LOGO]]

== '''Abstract''' ==
The Canster Truck Project is an autonomous RC car with CAN Bus interfaced controllers. The development of the RC car's subsystem modules (Interfacing of Ultrasonic Sensor, LIDAR, Bluetooth, GPS, Compass and CAN modules) was divided among six team members. The aim of the project is to develop an autonomous RC Car which can navigate from one source location to the selected destination on the app by avoiding obstacles in its path using sensors. Waypoints algorithm is used as the path finding technique.
 

== '''Introduction and Objectives''' ==

'''The project was divided into 7 modules:'''

* '''Bridge and Sensor Controller'''
* '''Motor Controller'''
* '''Geological Controller'''
* '''Driver and LCD Controller'''
* '''Hardware Integration'''
* '''Android Application'''
* '''Testing & Code Review'''

'''RC Car Objectives'''
'''1. Driver and LCD Controller''' - Handles algorithms for obstacle avoidance, route maneuvering, and waypoints
'''2. Geological Controller''' - Recieves coordinates from GPS and Heading from Compass for navigation
'''3. Motor Controller''' - Controls movements of the RC Car
'''4. Bridge and Sensor Controller''' - Detects surrounding objects and interfaces android application to controller via bluetooth
'''Team Objectives'''

[[File:CMPE243_S20_T2_High_Level_System_Diagram.png|thumb|center|800px| High Level System Diagram]]

 

== '''Team Members and Responsibilities''' ==
[[File:CMPE243_S20_T2_Canster Truck_Team.jpg|thumb|center|800px| Group Picture]]

'''Gitlab Project Link''' - [https://gitlab.com/coder137/can-ster_truck '''Canster Truck''']
 

*'''Niket Naidu''' [https://www.linkedin.com/in/niket-naidu-30090a134/ LinkedIn] [https://gitlab.com/coder137 Gitlab]
** '''Geological Controller''' : GPS, Compass, Waypoint Algorithm, Haversine and Bearing Angle logic
** '''Driver and LCD Controller''' : GLCD
** '''Bridge and Sensor Controller''' : Bluetooth
** '''Testing & Code Review'''

*'''Ganesh Ram Pamadi''' [https://www.linkedin.com/in/ganeshram93/ LinkedIn] [https://gitlab.com/ganeshram2493 Gitlab]
** '''Hardware Integration'''
** '''Testing & Code Review'''
** '''Driver Controller'''
** '''Motor Controller'''

*'''Nikhil Pabbisetty''' [https://www.linkedin.com/in/nikhilpabbisetty/ LinkedIn] [https://gitlab.com/nikhilpeoria Gitlab]
** '''Bridge and Sensor Controller'''
** '''Motor Controller'''
** '''Driver and LCD Controller'''
** '''Hardware Integration'''

*'''Akhil Cherukuri''' [https://www.linkedin.com/in/akhilcherukuri/ LinkedIn] [https://gitlab.com/akhilcherukuri Gitlab] [https://github.com/akhilcherukuri Github]
** '''Android Application'''
** '''Bridge and Sensor Controller'''

*'''Ashish Anant Ladage''' [https://www.linkedin.com/in/ashish-anant-ladage-7bb3a214b/ LinkedIn] [https://gitlab.com/ashishladage1 Gitlab]
** '''Driver and LCD Controller'''
** '''Hardware Integration'''
** '''Motor Controller'''

*'''Jesus De Haro De Reza''' [https://www.linkedin.com/in/jesus-de-haro-66342424/ LinkedIn] [https://gitlab.com/deharo27 Gitlab]
** '''Bridge and Sensor Controller'''
** '''Motor Controller'''

 

== '''Administrative Responsibilities''' ==
* '''Team Lead''' - [https://www.linkedin.com/in/niket-naidu-30090a134/ '''Niket Naidu''']
* '''Git Repository Manager''' - [https://www.linkedin.com/in/niket-naidu-30090a134/ '''Niket Naidu''']
* '''Bill Of Materials Manager''' - [https://www.linkedin.com/in/akhilcherukuri '''Akhil Cherukuri''']
* '''Wiki Report Manager''' - [https://www.linkedin.com/in/akhilcherukuri '''Akhil Cherukuri''']

 

== '''Schedule''' ==

{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-

! scope="row"| '''1'''
| style="text-align:center;" |'''02/11/2020'''
| style="text-align:center;" |'''02/17/2020'''
|
*'''Form teams and decide group name'''
*'''Review past projects'''
*'''Slack: Create project group and invite Preet'''
*'''GitLab: Create project groups repository'''
*'''Analysis of component required'''

|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''2'''
| style="text-align:center;" |'''02/18/2020'''
| style="text-align:center;" |'''02/24/2020'''
|
*'''Study CAN Communication'''
*'''Create Bill of Materials'''
*'''Order RC Car'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''3'''
| style="text-align:center;" |'''02/25/2020'''
| style="text-align:center;" |'''03/02/2020'''
|
*'''Setup team finance management using Splitwise application'''
*'''Complete Bill of Materials'''
*'''Order all other required components'''
*'''Wikipedia: Setup project report template'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''4'''
| style="text-align:center;" |'''03/03/2020'''
| style="text-align:center;" |'''03/09/2020'''
|
*'''Read the respective datasheets and manuals for each component'''
*'''Test each component for working conditions'''
|
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''5'''
| style="text-align:center;" |'''03/10/2020'''
| style="text-align:center;" |'''03/16/2020'''
|
*'''Assign team responsibilities and roles'''
*'''Setup team project management environment (ClickUp)'''
*'''Define CAN DBC'''
*'''Research GPS antennas and order'''
*'''Android: Environmental setup of Android Studio and enable version control'''
*'''Hardware : Decide PCB editing software (easyEDA)'''
*'''Hardware : Draft schematic for required PCB design'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''6'''
| style="text-align:center;" |'''03/17/2020'''
| style="text-align:center;" |'''03/23/2020'''
|
*'''Hardware : Create model of PCB''' 
*'''Android: Add a Button for changing bluetooth connection status in the application''' 
*'''Geological: Interface Compass module with SJ-2 board using I2C interface''' 
*'''Geological: Interface GPS module with SJ-2 board using the UART interface''' 
*'''Geological: Parse raw data to get meaningful values for GPS and Compass''' 
*'''Sensor: Interface and check the functionality of ultrasonic sensors to the SJ-2 board''' 
*'''Motor: Interface of Servo & DC motor to the SJ-2 board and check for basic functionality''' 
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''7'''
| style="text-align:center;" |'''03/24/2020'''
| style="text-align:center;" |'''03/30/2020'''
|
*'''Hardware : Finalize components placement on PCB.''' 
*'''Motor: Add PWM functionality and test the code on DC and servo motors''' 
*'''Sensor: Interface and check and study the output readings of Lidar sensor with SJ-2 board over UART''' 
*'''LCD Display: Explore UI designing of LCD''' 
*'''Hardware: Finalize on optimal ultrasonic sensor placements''' 
*'''Android: Initiate Bluetooth communication and show staus via text view''' 
*'''Wikipedia: Establish final wiki schedule'''
*'''Complete CAN communication format for each controller and link DBC file to the Wiki'''
*'''Complete high-level system block diagram'''
*'''Complete unit-level block diagrams'''
*'''Bridge: Interface HC-5 bluetooth module with Sj-2 board using serial communicaton'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''8'''
| style="text-align:center;" |'''03/31/2020'''
| style="text-align:center;" |'''04/06/2020'''
|
*'''Hardware: Analyze PCB model and order PCB Circuit board''' 
*'''Android: Initiate Bluetooth communication and send "Hello World".''' 
*'''Wikipedia: Start adding information/images/diagrams to the relevant sections'''
*'''Motor: Configure ESC for correct speed outcome according to frequency & PWM values''' 
*'''Motor: Finish RPM sensor hardware and software implementation and integration''' 
*'''Sensor: Read output from Lidar and setup structure for outputting for DBC''' 
*'''Geological: Implement waypoints algorithm''' 
*'''Driver: Implement obstacle avoidance algorithm''' 
*'''Bridge: Pass data such as "Hello World" from HC-05 bluetooth module to bluetooth terminal android application'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''9'''
| style="text-align:center;" |'''04/07/2020'''
| style="text-align:center;" |'''04/13/2020'''
|
*'''Hardware: Remove Unused parts from RC Car''' 
*'''Hardware: Mount PCB and 3D Parts''' 
*'''Motor: Decide different cut-off values from sensor to command right /slight right/ straight/ slight left/ left to motor.''' 
*'''Android: Embed Google Maps API for setting the car's destination.''' 
*'''LCD: Work to show RC cars live status information(battery level, current speed, long, lat, bearing, sensor data, etc)''' 
*'''Driver: Test obstacle avoidance algorithm and fine-tune sensor readings''' 
*'''Geological: Test checkpoint algorithm''' 
*'''Bridge: Establish two way communication between android application and bluetooth module''' 
*'''Update Bill of Materials for miscellaneous hardware'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''10'''
| style="text-align:center;" |'''04/14/2020'''
| style="text-align:center;" |'''04/20/2020'''
|
*'''Hardware: Integrate all hardware modules''' 
*'''LCD: Testing & Validation of the LCD UI and display vehicle status information''' 
*'''Android: Send car location to the app and checkpoints received to Geo module''' 
*'''Motor: Optimize PID control by accelerating/decelerating as instructed by Driver''' 
*'''Bridge: Configure HC-05 for auto reconnection if bluetooth communication disconnects''' 
*'''Add multiple debug messages and transmit on CAN'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''11'''
| style="text-align:center;" |'''04/21/2020'''
| style="text-align:center;" |'''04/27/2020'''
|
*'''Android: Send additional vehicle status information from RC car to the Application for display''' 
*'''Android: Finalize User Interface Design and Icon''' 
*'''Continuously test the whole system and handling of corner cases (outside).'''
*'''Finalize RC Car For Project Proto 1'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''12'''
| style="text-align:center;" |'''04/28/2020'''
| style="text-align:center;" |'''05/04/2020'''
|
*'''Gitlab: Push final code'''
*April 28th: Project Proto 1
*'''Finalize RC Car for Project Demo'''
*May 1st: Project Presentation
*'''Finalize RC Car for Project Proto 2'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''13'''
| style="text-align:center;" |'''05/05/2020'''
| style="text-align:center;" |'''05/21/2020'''
|
* '''Complete Individual Contribution Peer Grading'''
* '''Review and Complete Wiki Project Page'''
|
*'''Completed'''
*'''Completed'''
|-
|}

 

== '''Bill Of Materials''' ==
{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Item#
! scope="col"| Part Description
! scope="col"| Part Model & Vendor
! scope="col"| Quantity
! scope="col"| Cost in USD
|-
! scope="row"| 1
| '''Microcontroller Boards'''
| SJ2 Boards (Purchased from Preet Kang)
| 4
| $200.00
|-
! scope="row"| 2
| '''CAN Transceivers'''
| [https://www.waveshare.com/sn65hvd230-can-board.htm Waveshare SN65HVD230]
| 12
| $54.48
|-
! scope="row"| 3
| '''RC Car'''
| [https://www.amazon.com/Traxxas-Slash-Course-2-4GHZ-Vehicle/dp/B01DU474B0/ref=sr_1_3?ie=UTF8&qid=1474747759&sr=8-3&keywords=Traxxas+1%2F10+slash+2wd Traxxas 2WD RTR with 2.4Ghz Radio]
| 1
| $260.00
|-
! scope="row"| 4
| '''Lithium-Ion Battery'''
| [https://www.rcsuperstore.com/traxxas-7600mah-2s-7-4v-25c-id-lipo-battery-pack/ Traxxas 7600mAh 2S 7.4V 25C iD LiPo Battery Pack]
| 1
| $75.00
|-
! scope="row"| 5
| '''Lithium-Ion Battery Charger'''
| [https://www.amazon.com/Traxxas-2970-EZ-Peak-Charger-Identification/dp/B00OAFYLJC/ref=pd_bxgy_21_img_2?ie=UTF8&psc=1&refRID=JVX791WVV9Y8T9DW92KW Traxxas 2970 EZ-Peak Plus 4-Amp NiMH/LiPo Fast Charger]
| 1
| $50.00
|-
! scope="row"| 6
| '''Compass Breakout Board'''
| [https://www.dfrobot.com/product-1275.html DFRobot CMPS11 Compass]
| 1
| $29.99
|-
! scope="row"| 7
| '''Bluetooth Breakout Board'''
| [https://www.amazon.com/HC-05-Bluetooth-Pass-through-Wireless-Communication/dp/B01G9KSAF6/ref=sr_1_4?ie=UTF8&qid=1507077325&sr=8-4&keywords=arduino+bluetooth+hc-05 DSD TECH Bluetooth HC-05]
| 1
| $8.49
|-
! scope="row"| 8
| '''LIDAR Sensor'''
| [https://www.amazon.com/RPLiDAR-A1M8-Degree-Laser-Scanner/dp/B07H7X3SFF/ref=sr_1_fkmrnull_1?crid=2FSUI76G4UA8K&keywords=rplidar+a1m8+-+360+degree+laser+scanner+development+kit&qid=1552764172&s=gateway&sprefix=RPlidar%2Caps%2C263&sr=8-1-fkmrnull SEEED STUDIO RPLIDAR A1M8]
| 1
| $109.99
|-
! scope="row"| 9
| '''RPM Sensor'''
| [https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM Traxxas 6520 RPM Sensor]
| 1
| $13.70
|-
! scope="row"| 10
| '''GPS Breakout Board'''
| [https://www.adafruit.com/product/746 Adafruit Ultimate GPS Breakout v3]
| 1
| $44.30
|-
! scope="row"| 11
| '''LCD Display'''
| [https://4dsystems.com.au/ulcd-32ptu 4Dsystems 3.2 TFT-LCD ULCD-32PTU]
| 1
| $79.00
|-
! scope="row"| 12
| '''Ultrasonic Sensors'''
| [https://www.amazon.com/gp/product/B01COSN7O6/ ELEGOO HC-SR04 Ultrasonic Module]
| 5
| $12.00
|-
! scope="row"| 13
| '''GPS Antenna'''
| [https://www.amazon.com/dp/B07RRT615K/ GPS Antenna A1-UX]
| 1
| $10.98
|-
! scope="row"| 14
| '''PCB Fabrication'''
| [https://jlcpcb.com/ JLCPCB]
| 5
| $40.15
|-
! scope="row"| 15
| '''Miscellaneous'''
| [https://www.amazon.com Amazon],[https://www.mouser.com/ Mouser Electronics],[https://www.digikey.com/ Digikey],[https://anchor-electronics.com/ Anchor Electronics]
| ~
| $48.07
|-
! scope="row"|
|
|
| '''Total'''
| '''$1036.15'''
|-

|}

 

== '''Printed Circuit Board''' ==

=== Design And Architecture ===
The complete PCB (for boards and hardware peripherals) was designed using EasyEDA online software. The 4 nodes will be communicating via CAN bus and other peripherals are connected to the PCB via headers.

=== Power Section===
We have 2 power banks supplying our system. And the Servo Motor, RPM sensor and DC rear Motor (via ESC) are powered using LiPo battery (6 volts).
* Power bank #1 - Subset 2

* Power bank #2 - Subset 1, Subset 3, Bluetooth Module

'''NOTE:'''

'''Subset 1:'''
1. LIDAR
2. LCD
3. Compass

'''Subset 2:'''
1. Motor node
2. Driver node
3. BS node

'''Subset 3:'''
1. Geo node
2. Back ultrasonic sensor

=== Fabrication ===
* PCB was sent to fabrication to JLCPCB China which provided PCB with MOQ of 5 and 2 layers of PCB and common grounded the rest of the copper area.
'''DRC elements (in mils)'''
* Track Width = 12
* Clearance = 10
* Via Diameter = 24
* Via Drill Diameter = 12

=== Challenges ===
* Auto-routing gave lot of challenges (only ~60% success) and sometimes the online server even crashes and faces downtime. Even local routing had lot of issues. So make sure to plan your design accordingly.
* We started our PCB design well ahead of the project. So lot of pre-planning had to be done with regard to final hardware and placement of components in order to avoid spending extra time and money while re-ordering.
* The PCB went through a lot of internal revisions even before placing order. This was time-consuming.

'''Other hardware challenges:'''
* Figuring out why various hardware peripherals (GPS, Bluetooth, LIDAR and Ultrasonic sensor) started to malfunction (devices were on but values were either inconsistent / not occurring), took a lot of time to debug. It was due to insufficient power.

 
[[File:CMPE243 S20 T2 EasyEDA.png|1040x1200px|thumb|center|PCB Layout Design in EasyEDA]]
 
[[File:CMPE243 S20 T2 PCB SCHEMATIC.jpg|1041x550px|thumb|center|PCB Schematic]]
 
[[File:CMPE243 S20 T2 PCBFRONT.jpg|thumb|center|600px|PCB Top Layer]]
 
[[File:CMPE243 S20 T2 PCBBACK.jpg|thumb|center|600px|PCB Bottom Layer]]

 

== '''CAN Communication''' ==

=== Hardware Design ===
[[File:CMPE243_S20_T2_Canster_Truck_CANHW.png|thumb|center|770px| CAN Hardware Diagram]]

=== DBC File ===

DBC FILE: [https://gitlab.com/coder137/can-ster_truck/-/blob/dbc-improvements/projects/lpc40xx_freertos/project.dbc Gitlab]

<pre>
VERSION ""

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

BS_:

BU_: DBG DRIVER IO MOTOR SENSOR GEO

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" GEO,MOTOR,SENSOR

BO_ 101 GEO_HEARTBEAT: 1 GEO
SG_ GEO_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,MOTOR,SENSOR

BO_ 102 MOTOR_HEARTBEAT: 1 MOTOR
SG_ MOTOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,SENSOR

BO_ 103 SENSOR_HEARTBEAT: 1 SENSOR
SG_ SENSOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,MOTOR

BO_ 200 MOTOR_STEERING: 1 DRIVER
SG_ MOTOR_STEERING_direction: 0|8@1- (1,0) [-2|2] "" MOTOR

BO_ 210 DRIVER_COORDINATES: 8 DRIVER
SG_ DRIVER_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
SG_ DRIVER_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 220 MOTOR_SPEED: 1 DRIVER
SG_ MOTOR_SPEED_processed: 0|8@1- (1,0) [-3|3] "" MOTOR

BO_ 300 GEO_DEGREE: 8 GEO
SG_ GEO_DEGREE_current: 0|32@1+ (0.000001,0) [0|360] "degrees" DRIVER
SG_ GEO_DEGREE_required: 32|32@1+ (0.000001,0) [0|360] "degrees" DRIVER

BO_ 310 GEO_DESTINATION_REACHED: 1 GEO
SG_ GEO_DESTINATION_REACHED_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 400 MOTOR_SPEED_FEEDBACK: 4 MOTOR
SG_ MOTOR_SPEED_current: 0|32@1+ (0.1,0) [0|60] "kph" DRIVER

BO_ 500 SENSOR_BT_COORDINATES: 8 SENSOR
SG_ SENSOR_BT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
SG_ SENSOR_BT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 510 SENSOR_SONARS: 8 SENSOR
SG_ SENSOR_SONARS_left: 0|21@1+ (0.001,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right: 21|21@1+ (0.001,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle: 42|21@1+ (0.001,0) [0|0] "cm" DRIVER

BO_ 520 SENSOR_LIDAR: 8 SENSOR
SG_ SENSOR_LIDAR_middle: 0|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_slight_left: 16|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_slight_right: 32|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_back: 48|16@1+ (1,0) [0|0] "cm" DRIVER

BO_ 530 MOTOR_KEY: 1 SENSOR
SG_ MOTOR_KEY_val: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 900 GEO_CURRENT_COORDINATES: 8 GEO
SG_ GEO_CURRENT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" DBG
SG_ GEO_CURRENT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" DBG

BO_ 901 GEO_DISTANCE_FROM_DESTINATION: 4 GEO
SG_ GEO_distance_from_destination: 0|32@1+ (0.001,0) [0|0] "meters" DBG

BO_ 902 MOTOR_INFO_DBG: 4 MOTOR
SG_ MOTOR_INFO_DBG_rps: 0|16@1+ (1,0) [0|0] "" DBG
SG_ MOTOR_INFO_DBG_pwm: 16|16@1+ (0.001,0) [0|0] "" DBG

BO_ 903 LIPO_BATTERY_VOLTAGE_DBG: 4 MOTOR
SG_ LIPO_BATTERY_VOLTAGE_val: 0|32@1+ (0.01,0) [0|0] "volts" DBG

BO_ 904 CURRENT_CHECKPOINT_DBG: 1 GEO
SG_ CURRENT_CHECKPOINT_val: 0|8@1+ (1,0) [0|0] "" DBG

CM_ "--BU (Network Node) Information--";
CM_ BU_ DRIVER "The driver controller of the car";
CM_ BU_ GEO "The geo controller of the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";

CM_ "--BO (Message) Information--";
CM_ BO_ 100 "Driver Sync message used to synchronize the controllers";
CM_ BO_ 101 "Geo Sync message used to synchronize the controllers";
CM_ BO_ 102 "Motor Sync message used to synchronize the controllers";
CM_ BO_ 103 "Sensor Sync message used to synchronize the controllers";

CM_ BO_ 200 "Steering direction values sent by Driver Node to Motor Node";
CM_ BO_ 210 "Driver Destination coordinates sent by Driver Node";
CM_ BO_ 220 "Required motor speed computed from Driver Node to Motor Node";

CM_ BO_ 300 "Current and computer/required degree values sent by Geo Node";
CM_ BO_ 310 "Indicator signal to check if the RC car has reached the destination";

CM_ BO_ 400 "Current motor info (rps and kph) sent as feedback to the Driver Node";

CM_ BO_ 500 "Coordinate BT values (destination coordinates) sent by Sensor Node";
CM_ BO_ 510 "LIDAR - Distance from obstacle detected in each sector";
CM_ BO_ 520 "Ultrasonic Sensor - Distance from obstacle detected by each sensor";
CM_ BO_ 530 "Start/Stop signal from the Bluetooth app";

CM_ BO_ 900 "Destination coordinates for BUSMASTER debugging";
CM_ BO_ 901 "Distance from destination";
CM_ BO_ 902 "Supplied PWM value to the motor and its RPM";
CM_ BO_ 903 "LIPO Battery Voltage";
CM_ BO_ 904 "Current checkpoint of the car";

CM_ "--SG (Signal) Information for Heartbeats--";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver node";
CM_ SG_ 101 GEO_HEARTBEAT_cmd "Heartbeat command from the geological node";
CM_ SG_ 102 MOTOR_HEARTBEAT_cmd "Heartbeat command from the motor node";
CM_ SG_ 103 SENSOR_HEARTBEAT_cmd "Heartbeat command from the sensor node";

CM_ "--SG (Signal) Information for DRIVER Node--";
CM_ SG_ 200 DRIVER_STEERING_direction "Calculated Driver Steering values (-2,2) for Motor";
CM_ SG_ 210 DRIVER_COORDINATES_latitude "Destination Latitude coordinate";
CM_ SG_ 210 DRIVER_COORDINATES_longitude "Destination Longitude coordinate";
CM_ SG_ 220 MOTOR_SPEED "Calculated Driver speed values (-3,3) for Motor";

CM_ "--SG (Signal) Information for GEO Node--";
CM_ SG_ 300 GEO_DEGREE_current "Current Geo Degree relative to true north";
CM_ SG_ 300 GEO_DEGREE_required "Calculated Geo Degree computed by Haversine Formula";
CM_ SG_ 310 GEO_DESTINATION_REACHED "Indicator signal to check if the RC car has reached the destination";

CM_ "--SG (Signal) Information for MOTOR Node--";
CM_ SG_ 400 MOTOR_SPEED_FEEDBACK "Feedback speed (kph) sent by Motor Node";

CM_ "--SG (Signal) Information for SENSOR Node--";
CM_ SG_ 500 SENSOR_BT_COORDINATES_latitude "Destination Latitude received over Bluetooth";
CM_ SG_ 500 SENSOR_BT_COORDINATES_longitude "Destination Longitude received over Bluetooth";
CM_ SG_ 510 SENSOR_SONARS_left "Ultrasonic Sensor attached to the left side";
CM_ SG_ 510 SENSOR_SONARS_right "Ultrasonic Sensor attached to the right side";
CM_ SG_ 510 SENSOR_SONARS_middle "Ultrasonic Sensor attached to the middle";
CM_ SG_ 510 SENSOR_SONARS_back_left "Ultrasonic Sensor attached to the back left side";
CM_ SG_ 510 SENSOR_SONARS_back_right "Ultrasonic Sensor attached to the back right side";
CM_ SG_ 520 SENSOR_LIDAR_middle "Lidar sensing the middle sector (-15 to 15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_left "Lidar sensing the slight left sector (-45 to -15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_right "Lidar sensing the slight right sector (15 to 45 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_back "Lidar sensing the back of the car (165 to 195 degrees)";
CM_ SG_ 530 MOTOR_KEY_val "1 -> Start the motor from the app, 0 -> Stop";

CM_ SG_ 900 GEO_CURRENT_COORDINATES_latitude "Current Latitude";
CM_ SG_ 900 GEO_CURRENT_COORDINATES_longitude "Current Longitude";
CM_ SG_ 901 GEO_distance_from_destination "Distance from destination";
CM_ SG_ 902 MOTOR_INFO_DBG_rps "Current RPS value of the motor";
CM_ SG_ 902 MOTOR_INFO_DBG_pwm "Supplied motor PWM value";
CM_ SG_ 903 LIPO_BATTERY_VOLTAGE_val "LIPO Battery Voltage";
CM_ SG_ 904 CURRENT_CHECKPOINT_val "Current checkpoint of the car";

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

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

BA_ "GenMsgCycleTime" BO_ 100 1000;
BA_ "GenMsgCycleTime" BO_ 200 50;
BA_ "FieldType" SG_ 100 DRIVER_HEARTBEAT_cmd "DRIVER_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 102 GEO_HEARTBEAT_cmd "GEO_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 103 MOTOR_HEARTBEAT_cmd "MOTOR_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 104 SENSOR_HEARTBEAT_cmd "SENSOR_HEARTBEAT_cmd";

BA_ "FieldType" SG_ 200 MOTOR_STEERING "MOTOR_STEERING";
BA_ "FieldType" SG_ 230 MOTOR_SPEED_val "MOTOR_SPEED_val";
BA_ "FieldType" SG_ 310 GEO_DESTINATION_REACHED_cmd "GEO_DESTINATION_REACHED_cmd";

VAL_ 100 DRIVER_HEARTBEAT_cmd 2 "DRIVER_HEARTBEAT_cmd_REBOOT" 1 "DRIVER_HEARTBEAT_cmd_SYNC" 0 "DRIVER_HEARTBEAT_cmd_NOOP" ;
VAL_ 101 GEO_HEARTBEAT_cmd 2 "GEO_HEARTBEAT_cmd_REBOOT" 1 "GEO_HEARTBEAT_cmd_SYNC" 0 "GEO_HEARTBEAT_cmd_NOOP";
VAL_ 102 MOTOR_HEARTBEAT_cmd 20 "MOTOR_HEARTBEAT_cmd_REBOOT" 10 "MOTOR_HEARTBEAT_cmd_SYNC" 0 "MOTOR_HEARTBEAT_cmd_NOOP" ;
VAL_ 103 SENSOR_HEARTBEAT_cmd 200 "SENSOR_HEARTBEAT_cmd_REBOOT" 100 "SENSOR_HEARTBEAT_cmd_SYNC" 0 "SENSOR_HEARTBEAT_cmd_NOOP" ;

VAL_ 200 MOTOR_STEERING_direction -2 "MOTOR_STEERING_hard_left" -1 "MOTOR_STEERING_slight_left" 0 "MOTOR_STEERING_straight" 1 "MOTOR_STEERING_slight_right" 2 "MOTOR_STEERING_hard_right";
VAL_ 220 MOTOR_SPEED_processed -3 "MOTOR_SPEED_reverse_fast" -2 "MOTOR_SPEED_reverse_medium" -1 "MOTOR_SPEED_reverse_slow" 0 "MOTOR_SPEED_neutral" 1 "MOTOR_SPEED_forward_slow" 2 "MOTOR_SPEED_forward_medium" 3 "MOTOR_SPEED_forward_fast";
VAL_ 310 GEO_DESTINATION_REACHED_cmd 1 "GEO_DESTINATION_REACHED_cmd_REACHED" 0 "GEO_DESTINATION_REACHED_cmd_NOT_REACHED";
</pre>

 

== '''Motor Controller''' ==
'''[https://gitlab.com/coder137/can-ster_truck/-/tree/motor_bleeding_edge_dev GitLab Link]'''

This controller is used to control the components of the car-related to motor. We can control the speed and steering of the car having interfaced with various components with the SJ-2 board. The servo motor is controlled via PWM and is used to set the steering direction of the car. The DC motor is controlled by the Electronic Speed Controller (ESC) via PWM for speed. We read the speed of the car by using an RPM sensor. By using the RPM sensor values, a feedback loop has been designed to regulate the speed of the car. A state machine has been designed to manage the forward and backward movements of the car.
Additionally, a voltage divider circuit has been implemented to read the battery voltage. All motor functionality and CAN message communication is run at 10 Hz.

=== Hardware Design ===

[[File:CMPE243_S20_T2_Canster_Truck_Motor_Hardware.png|thumb|center|750px| Motor Hardware System]]

The following diagram details the hardware implementation of the motor module with the SJTwo board:
Hardware Interface
=====Servo Motor=====
The servo motor responds to PWM pulses. It has three pins namely Vcc, PWM Input Signal, and GND. The servo is powered using 6V from the car battery. Based on the PWM signal supplied from the SJTwo board the front wheels are turned.
[[File:CMPE243_S20_T2_Canster_Truck_Motor_1.jpg|440px|thumb|center|| Servo Motor]]
{| class="wikitable" style="text-align: center; width: 400px; height: 200px; margin: left;"
|+ Servo Motor Pin Connection
|-
! Sr. No.
! Wires - Servo Motor
! Function
|-
! 1
| PWM Connected to P2.5 || PWM Signal from Sj-2 Board
|-
! 2
| VCC || 6V supply from ESC
|-
! 3
| GND || Common Ground
|-
|}

=====Electronic Speed Controller (ESC)=====
The ESC is used to control the DC motor. It is supplied power using the 7.4 V LiPo battery. It has three pins namely Vout, PWM Input Signal, and GND. Based on the PWM input signal, the speed and forward, neutral, and backward movements of the car is changed. Vout is given to the RPM sensor and Servo motor.
[[File:CMPE243_S20_T2_Canster_Truck_Motor_2.jpg|440px|thumb|center|| Electronic Speed Controller (ESC)]]
{| class="wikitable" style="text-align: center; width: 400px; height: 200px; margin: left;"
|+ Speed Sensor Pin Connection
|-
! Sr. No.
! Wires - RPM Sensor
! Function
|-
! 1
| Signal Wire Connected to P2.0 || GPIO that supplies pulses to controller
|-
! 2
| VCC || 6V supply from ESC
|-
! 3
| GND || Common Ground
|-
|}

=====DC Motor=====
The DC motor is controlled using the ESC. It has two pins, a positive and a negative terminal. A PWM signal wire is connected to the microcontroller and the required current is provided by the LiPo battery and the ESC. The DC motor is controlled using PWM at 10Hz.

[[File:CMPE243_S20_T2_Canster_Truck_Motor_3.jpg|320px|thumb|center|| DC Motor]]
{|
|-
|
{| class="wikitable" style="text-align: center; width: 400px; height: 200px; margin-left:0px;"
|+ DC Motor Pin Connection
|-
! Sr. No.
! Wires - DC Motor
! Description
|-
! 1
| Positive Wire (already connected) || Positive Terminal
|-
! 2
| Negative Wire (already connected || Negative Terminal
|-
|}
 
{| class="wikitable" style="text-align: center; width: 400px; height: 200px;"
|+ DC Motor Configuration
|-
! Operation
! Pulse Width Range (ms)
! Duty Cycle(%)
|-
! FORWARD
| 1.51 - 2.00 || 15.1-20.0
|-
! STOP
| 1.50 || 15.0
|-
! REVERSE
| 1.00 - 1.49 || 10.0-14.9
|-
|}
|
|-
|}

Note: First calibrate the DC motor or the motor will not respond to your PWM pulses. For help with calibration go to this [https://traxxas.com/support/Programming-Your-Traxxas-Electronic-Speed-Control website]

=====RPM Sensor=====

The RPM sensor is used to get the current speed of the car. We use the info for creating a feedback loop (PID) for maintaining the speed of the car in uphill and downhill situations. The RPM sensor mounts on the rear DC motor shaft compartment with a special assembly also provided by Traxxas. The magnet which attached to the inner gear generates a pulse each rotation. The sensor works on the hall effect principle where it provides a current across its terminal when placed in a magnet's field. The RPM sensor has three pins namely Vcc, Signal, and GND.

[[File:CMPE243_S20_T2_Canster_Truck_Motor_4.jpg|440px|thumb|center|| RPM Sensor]]

{| class="wikitable" style="text-align: center; width: 400px; height: 200px; margin: left;"
|+ Speed Sensor Pin Connection
|-
! Sr. No.
! Wires - RPM Sensor
! Function
|-
! 1
| Signal Wire Connected to P2.2 || GPIO that supplies pulses to controller
|-
! 2
| VCC || 6V supply from ESC
|-
! 3
| GND || Common Ground
|-
|}

=== Software Design ===

The software for the motor node was divided into multiple files and made modular to improve readability and understanding of the complex logic involved. The main code modules are for:
*Servo Motor
*Electronic Speed Controller
*RPM Sensor
*Motor Wrapper
*Battery Voltage

The motor wrapper module is used to wrap all the code from the esc, servo, and rpm modules into simple to use functions to be called in the periodic tasks.
=====Servo Motor=====
It uses the steering value sent from the driver (-2 to 2) and matches it to the appropriate PWM value for steering. This code module is run at 10Hz.
<pre>
void servo__steer_processor(int16_t steering_value) {
switch (steering_value) {
case MOTOR_STEERING_hard_left:
servo__steer_hard_left();
break;
case MOTOR_STEERING_slight_left:
servo__steer_soft_left();
break;
case MOTOR_STEERING_straight:
servo__steer_straight();
break;
case MOTOR_STEERING_slight_right:
servo__steer_soft_right();
break;
case MOTOR_STEERING_hard_right:
servo__steer_hard_right();
break;
default:
printf("\nDid not receive steering value");
}
}
</pre>
=====Electronic Speed Controller=====

This code module is used to control the DC motor. It receives the motor direction value from the driver and sets the appropriate PWM value. Based on the value the motor is commanded to move the car forward or backwards. A switch case is implemented to set PWM values for movement in different directions along with different speeds.
<pre>
void esc__direction_processor(int16_t direction_value) {
desired_direction_value = direction_value;
switch (direction_value) {
case MOTOR_SPEED_reverse_fast:
esc__reverse_fast();
break;
case MOTOR_SPEED_reverse_medium:
esc__reverse_medium();
break;
case MOTOR_SPEED_reverse_slow:
esc__reverse_slow();
break;
case MOTOR_SPEED_neutral:
esc__neutral();
break;
case MOTOR_SPEED_forward_slow:
esc__forward_slow();
break;
case MOTOR_SPEED_forward_medium:
esc__forward_medium();
break;
case MOTOR_SPEED_forward_fast:
esc__forward_fast();
break;

default:
printf("\nDid not receive direction and speed value");
}
}
</pre>

There is also a feedback loop to control the speed. The ESC code depends on the rpm sensor code for the current speed values.
<pre>
double current_speed = get_speed_kph();
double desired_speed = desired_speed_kph;
float adjusted_duty_cycle = 0.0;
adjusted_duty_cycle = duty_cycle + (speed_to_pwm_adjustment(desired_speed, current_speed));
</pre>

[[File:CMPE243_S20_T2_Canster_Truck_Motor1.png|thumb|center|500px| Feedback Loop for Motor Speed]]

=====RPM Sensor=====
This code module is used to get current speed data from the RPM sensor. It is based on interrupts. When the wheel rotates once, we get one pulse due to the magnet installed. This pulse generates a falling edge interrupt during which we increment the pulse counter. Since, this code is run at 1Hz we collect the number of pulses generated every one second. This gives us the number of rotations per second using which we can calculate the speed in kph.
<pre>
float rpm__calculate_speed_kph() {
uint16_t rotation_per_sec = pulse_count;
pulse_count = 0;
speed_kph = ((CIRCUMFERENCE_METER * rotation_per_sec) * (MPS_TO_KPH_CONVERSION_FACTOR)) / GEAR_RATIO;
return speed_kph;
}
</pre>

=====Motor Wrapper=====
As mentioned above, the main function of this code module is to wrap all the other code modules and call the right functions at the appropriate frequency. The motor wrapper code also includes a state machine for ensuring a smooth transition between forward to backward state and vice versa. In order to achieve a smooth transition, a series of PWM pulses must be generated at the right time. For example, when the motor is moving from forward to backward state, a reverse value must be given first followed by at least three neutral values, and then continue with reverse values.

[[File:CMPE243_S20_T2_Canster_Truck_Motor2.png|thumb|center|500px| State Machine Flowchart for Motor Movements]]

=====LiPo Battery Voltage=====

The LiPo Battery Voltage was calculated using ADC in Burst Mode. A LiPo Hardware module was created for the same which contained two functions, <code>lipo__init</code> and <code>lipo__get_voltage</code>.

The voltage divider circuit is stepped down from 7.4V to 2.1V using 10K and 4K Resistor pair.
[[File:CMPE243_S20_T2_Canster Truck_Motor_Voltage_Regulator.png|thumb|center|400px| Voltage Regulator]]
'''LiPo Initialization'''

The LiPo Initialization phase initializes the ADC, Enables Burst mode on the ADC pins and configures the Alternate Function Registers for the same.

'''Getting LiPo Voltage'''

We read the raw ADC value from the LPC Hardware register. This value will be from 0 - 3.3V. However due to our voltage divider configuration the max voltage that we should theoretically get is 2.1V. This means that 2.1V corresponds to 7.4V of the LIPO Battery voltage.

The formula used is
<code>(raw_adc_value * MAX_LIPO_BATTERY_VOLTAGE_VALUE) / MAX_LIPO_ADC_VALUE</code>

=== Technical Challenges ===
<li>Changing movements of the car from Forward to Backward and vice versa
If you just change the PWM value from say 16 (Forward) to 14(Backward), the DC motor will just stop and will not make wheels turn reverse. We discovered this problem quite late as during the initial testing we had always run the car from the start with either forward or reverse but never tried changing the direction during run-time.
 
Solution: The motor requires a series of PWM pulses which is specific to the car to transition from forward mode to reverse mode. In our case we had to give the PWM pulses in the following sequence. Suppose,
<ol>
<li> Forward (16) (callback_count = 0)</li>
<li> Forward (16) (callback_count = 1)</li>
<li> Reverse (14) (callback_count = 2)</li>
<li> Neutral (15) (callback_count = 3)</li>
<li> Neutral (15) (callback_count = 4)</li>
<li> Neutral (15) (callback_count = 5)</li>
<li> Reverse (14) (callback_count = 6)</li>
<li> Continue reverse</li>
</ol>
Similarly, the reverse to forward can also be implemented.
<li>DC motor shooting off when there is an improper ground connection
When we connected the battery voltage circuit for reading the voltage from the battery, the motor would randomly shoot off every now and then.
 
Solution: Connect the voltage divider circuit to the common ground rather than taking the ground from the ESC.</li>

 

== '''Geological Controller''' ==
'''[https://gitlab.com/coder137/can-ster_truck/-/tree/geo_bleeding_edge_dev_waypoints GitLab Link]'''

===Messages===
*GEO_HEARTBEAT: Used to check for MIA by other nodes. Highest priority message for GEO Node

*GEO_DEGREE: Sends the current degree relative to the North Pole computed by the Compass and the Required degree relative to the North Pole computed by Bearing Angle using the Current Coordinate and Destination Coordinate.

*GEO_DESTINATION_REACHED: Sets a flag, 0 for destination not reached and 1 for destination reached

*GEO_CURRENT_COORDINATES: Debug Message used to send the Current GPS Coordinates

*GEO_DISTANCE_FROM_DESTINATION: Debug message used to send the Distance from Destination

*CURRENT_CHECKPOINT_DBG: Debug message used to check which checkpoint is being navigated to

=== Hardware Design ===

[[File:CMPE243_S20_T2_GEO1.png|thumb|center|650px| Geological Diagram]]

=== Software Design ===
=====Overview=====
*Inside the `periodic_callback__initialize`
**Initialize the CAN BUS
**Initialize the GPS

*Inside the `periodic_callback__1hz`
**Handle all MIA (from other Nodes)
**Update GPS LED when init and in case of failure
**Compute the GEO logic for Waypoints algorithm once every second (1000 ms)

*Inside the `periodic_callback__10hz`
**Handle CAN Incoming messages (Decode)
**Transmit CAN Geo messages (Encode and send)
**Compute the GPS Coordinate

=====Compass I2C Driver=====
An online datasheet resource was used to work with the Compass ([https://www.robot-electronics.co.uk/htm/cmps11i2c.htm CMPS11 Datasheet])
Initially the Compass I2C Driver was tested using the Terminal I2C Helper built by our Professor Preetpal Kang. Using this resource we were quickly able to read various I2C Registers and display it onto the terminal.

For our project the only required part of the Compass was the 16-bit Compass Bearing value (0-3599) i.e 0-359.9 degree values. These values were stored in the 2nd and 3rd register (Register 2 being the High Byte).
Once the raw data was received over I2C we could easily combine the data

<pre>
uint16_t bearing_value = (Reg2 << 8) | Reg3;
float rval = bearing_value / 10.0;
return rval;
</pre>
The returned value were transmitted to the Driver Node to compute its steering based on the required Bearing Angle.

=====GPS Initialization=====
GPS Initialization activates the Hardware GPIO (RX and TX), FreeRTOS Queue for UART Interrupts (UART Module) and Line Buffer Module to parse each GPS line.

=====GPS Data Parsing=====
The GPS Hardware module transmits an NMEA string over UART to the SJTwo Board. We read each character one by one and add it to the Line Buffer module.
Inside its computation loop, the Line Buffer module checks if a newline character has been received.
When a newline character has been received the entire string is extracted from the line buffer module and parsed according to its identifier ($GPRMC, $GPGGA) received and parsed into individual tokens.
For our purposes the $GPRMC NMEA string was the most appropriate and it helped us extract the Current Latitude Longitude as well as the Valid/Invalid tag for the Canster Truck.

=====GPS LED Indication for debugging=====

A simple module that checks for the GPRMC GPS Message and extracts the A or V valid (Tag). If $GPRMC NMEA string is valid, LED is set, else LED is reset. This gives us onsite debugging capabilities to know if GPS has locked onto a satellite signal.

=====GEO Logic Module Computation=====
The GEO Logic Module computes the Bearing Angle, Haversine Distance as well as the Waypoints algorithm.

'''Bearing Angle:'''

<code>
θ = atan2( sin Δλ ⋅ cos φ2 , cos φ1 ⋅ sin φ2 − sin φ1 ⋅ cos φ2 ⋅ cos Δλ )
</code>

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

Since atan2 returns values in the range -π ... +π (that is, -180° ... +180°), to normalize the result to a compass bearing (in the range 0° ... 360°, with −ve values transformed into the range 180° ... 360°), convert to degrees and then use (θ+360) % 360, where % is (floating point) modulo.
For final bearing, simply take the initial bearing from the endpoint to the start point and reverse it (using θ = (θ+180) % 360).

The above article reference gives us the required bearing angle that our car must align itself to, to reach a particular destination coordinate from its current coordinate.
The Steering of the vehicle depends on the above-computed angle values.

'''Haversine Distance Formula:'''

This uses the ‘haversine’ formula to calculate the great-circle distance between two points – that is, the shortest distance over the earth’s surface – giving an ‘as-the-crow-flies’ distance between the points (ignoring any hills they fly over, of course!).

<code>
a = sin²(Δφ/2) + cos φ1 ⋅ cos φ2 ⋅ sin²(Δλ/2)

c = 2 ⋅ atan2( √a, √(1−a) )

d = R ⋅ c
</code>

where φ is latitude, λ is longitude, R is earth’s radius (mean radius = 6,371km);
note that angles need to be in radians to pass to trig functions!

The above formula is used to calculate the distance between the source coordinate (received via GPS) and the destination coordinate.
Later this was used to compute the distance between source coordinate and each individual checkpoint to traverse the shortest distance.

'''Waypoints Algorithm:'''

The Waypoints algorithm that was chosen was a slightly modified version of Djikstra’s Algorithm.
3 values were calculated before the final computation

* Distance between source and final destination (DISTsd)
* Distance between source and each individual checkpoint (DISTsc)
* Distance between each individual checkpoint and the final destination. (DISTcd)

If '''DISTsd''' was lesser than '''DISTcd''', this checkpoint was discarded (we continue in the loop). Since we would be moving in the opposite direction, rather than towards the final destination.

If '''DISTsd''' was greater than '''DISTcd''', then we checked the nearest checkpoint to the source.
The minimum value was set initial that was equal to '''DISTsd'''.

If '''DISTsc''' was lesser than the minimum value stored, '''DISTsc''' would become the new minimum value, and the checkpoint index and coordinates would be appropriately stored and returned from the function.

In this way we would navigate to the nearest checkpoint from the source, while also making sure NOT to travel in the opposite direction.
This logic is recomputed only when we reach the checkpoint selected and the algorithm runs again to find the next checkpoint that we need to navigate to.

=====CAN Decode Destination Coordinates=====
Destination Coordinates are received from the Bridge and Sensor Node and transmitted over the CAN Bus. The value is decoded and stored in the GEO Logic Module.
This is a very important value since our entire GEO Logic calculations are based on the Destination Coordinate.

=====CAN Encode and Send=====

The main messages that were transmitter are
#Geo Degree
#Geo Destination Reached
#Distance from Destination Debug and Checkpoint Index debug

'''Geo Degree Computation as per Waypoints Algorithm:'''

Geo Degree was computed as per the current coordinates and the most recently computed checkpoint coordinates. This bearing angle calculation w.r.t computed checkpoint would continue till we do not reach that particular checkpoint.
Once we reach the computed checkpoint, Waypoint algorithm is recomputed as per the process mentioned above and the algorithm runs again.

'''Geo Destination Reached:'''

An Area of around 4 meters was set around the destination coordinate to check if the destination had been reached.
This measurement was taken into consideration to allow for the loss in precision when transmitting data over CAN as well as any irregularities that might occur when getting values from the GPS.
Having an area of 4 meters was very accurate for all of our test runs.

'''Geo Distance from Destination Debug and Checkpoint Index Debug:'''

Getting debug information was very critical to speed up our development process. In this case we could actively see if our algorithm worked properly.
The Geo Distance from Destination was used to see if we were moving closer to our destination or veering further away from it.
The Checkpoint Index was used to see which checkpoint index we were traveling to. By knowing the placements of the Individual checkpoints we could manually as well as programmatically (via Android application) verify the working of our Canster Truck.

=== Technical Challenges ===
#DBC Challenge for GEO Coordinates -> Could not encode more than 5-6 decimal places at a time, on later investigation we found that the 10000 is an int value, however 100000 overflows the int value.
#Creating an efficient algorithm for Waypoints, O(n) complexity.
#Getting appropriate fixes for GPS when not in a completely open space.
#GPS used to fluctuate or stop giving values when Battery voltage went below a particular threshold. Always supply 3.3V constantly at a good amperage.

 

== '''Sensor [Bridge and Sensor Controller]''' ==
'''[https://gitlab.com/coder137/can-ster_truck/-/tree/sensor_bleeding_edge_dev GitLab]'''
==='''Ultrasonic Sensor'''===
====Hardware Design====
This sensor uses an ultrasonic beam to measure the distances. Based on the time taken between when the beam is sent and received back to the sensor, the distance is calculated in the node.
Apart from 5v and GND, this sensor has 2 pins ECHO and TRIG which are interfaced with the SJ-Two board via GPIO.

[[File:CMPE243_S20_T2_CansterTruck_ultrasonic_sensor.jpg|thumb|center|300px| Ultrasonic Sensor Diagram]]

====Software Design====
* Init the GPIO pin connected to TRIG of the sensor as output and for ECHO as an input port.
* Attach the interrupt on the ECHO input port.
* Store the system_clock_count before setting the trigger pulse and then set the pulse. Also keep monitoring the input port.
* Take the system_clock_count at the instant of receiving the interrupt.
Distance = (system_clock_count_at_trig - system_clock_count_after_at_echo) / 57.14

==='''Lidar Sensor'''===
====Hardware Design====
The RPLidar sensor can be powered from a 5v source and uses UART communication to receive commands and transmit data. It has seven pins to interface with. Two sets of the pins (four total) are for power and ground. The remaining three are for UART receive and transmit, and for making the lidar’s motor spin.

[[File:CMPE243_S20_T2_Canster_Truck_RPLidar_A1.JPG|thumb|center|300px| RPLidar A1]]

====Software Design====
In terms of the lidar, the SJ2 initializes GPIO, UART, and memory for storing the measurement values. After initialization, the command to begin scanning is sent. Here, we wait for the lidar to send a response packet, letting the host (SJ2 board) know it received the command. The response packet the lidar sends will be 7 bytes. If the correct 7 bytes are not received, the command will be sent again.

[[File:CMPE243_S20_T2_Canster Truck_Lidar_flow.jpeg|thumb|center|200px| Lidar Flow]]

Following the response packet, the lidar begins sending 5-byte measurement data. Each sample contains a distance measurement (in millimeters) and the angle (with respect to the lidar) in which it was taken. The data packet structure is shown in the following figure. In addition to containing the distance and angle, the packet includes a quality value, to indicate the reliability of the measurement, and three check bits (S, ~S, and C). As the data is received via UART, we wait until we have 5 bytes before continuing to process. Before processing the 5 bytes after receiving them, the check bits are confirmed to be correct. If they are incorrect, it will not be processed and we will wait for another sample to be received.

[[File:CMPE243_S20_T2_Canster Truck_DataPacketStructure.JPG|thumb|center|200px| Data Packet Structure]]

In the case the sample is correct, each measurement value that is in a direction of interest will be placed in an array designated to one of four directions (left, right, front, rear). Each of these directions have their own sector in the lidar’s 360-degree view.
*Right sector: 11° - 30°
*Rear sector: 170° - 190°
*Left sector: 330° - 349°
*Front sector: 350° - 370° (or 10°)

The arrays mentioned will hold roughly 20 measurements, which are every degree in the sector. In the event, objects are too far to measure, the lidar will report 0 mm. distance. Since there is no measurable obstacle, a “large” distance value of 3000 mm. is placed in the array. The smallest distance value will be taken from each array and reported to the driver node for obstacle avoidance.

=== Technical Challenges ===
====Ultrasonic Sensor====
*'''Power issue''' The pulses were getting triggered incorrectly and it took a while to figure out that it was due to insufficient power.

====LIDAR====
*'''Datasheet not 100% clear:''' The correct datasheet for the was a bit difficult to obtain, and the manufacturer needed to be contacted. The first document found online was high level and general information about the sensor, but the manufacturer did provide another document that contained the information of the commands and responses to and from the lidar, and their packet structure. The documents did not clearly state the angles with respect to the lidar are fixed, which left me wondering if the lidar will think the direction it is facing when powered on will become the new “zeroth” angle.

*'''UART Buffer Overflow:''' When first interfacing with the sensor, the incoming bytes of the lidar were printed on to the terminal to make sure there was a response and to make sense of the information. Since the command we sent results in 5 bytes of data per measurement samples from the lidar and the lidar measured 2000 times per second, there are will be roughly 10k Bytes per second of data incoming that need to be handled continuously. With an improperly sized UART buffer and print statements it is guaranteed to occur, making the lidar data look like random values.

*'''Proper Parsing of Measurement Data:''' After sending a command to the lidar, the sensor will send a response packet, followed by the measurement data. The initial response from the lidar is a 7-byte packet, followed by continuous 5-byte measurement samples. I needed to make sure however I handled the response would be independent of how the measurement is handled, so as not to create a potential unwanted offset when receiving measurements.

*'''Object Detection with Received Data:''' Once proper communication was set up with the lidar and measurement data was getting decoded, there needed to be a way to measure when obstacles were present. If ~360 measurements are handled entirely independently from one another, it could become a complex and confusing code. To achieve a simple approach, four sectors about 20 degrees in size were used to represent the front, left, right, and rear directions.

*'''Bugs in Code:''' When first implementing the code, there were a few bugs from typos, incorrect numbers, and some faulty logic that were found with the use of unit testing. Unit testing helped find these issues and verified the logic was correct, and I would say gave me 90% confidence in my lidar handling.

 

== '''Bluetooth Module [Bridge and Sensor Controller]'''==

Bridge functionality of the Bridge and Sensor Controller is to establish wireless communication between the SJ-2 Board and the android mobile device using the HC-05 Bluetooth module. The Bridge controller will be receiving start command with destination GEO coordinates and stop command. The Bridge controller will be transmitting the required sensor data and debug information to be displayed on the android application.

[[File:CMPE243_S20_T2_BRIDGE.png|thumb|center|500px| Bridge Diagram]]

==== Software Design ====

'''Low-Level Layer'''

In this layer, similar to the GPS the UART GPIO was initialized (RX, TX), FreeRTOS Queue was initialized for UART Interrupts and the line buffer module was initialized to parse strings.

Two basic functions <code>bt__read</code> and <code>bt__write</code> were implemented.
As the name suggested, <code>bt__write</code> took a string as its input parameter and transmitted that data to the Android application. <code>bt__read</code> stored the incoming characters into the line buffer, parsed the line received into its identifier and tokens, and invoked a callback function.

Since this was a low-level layer the User would not be directly invoking this library. Instead a '''Bluetooth Wrapper''' module was created which would be invoked and used by the user.

'''Application Layer'''

The Bluetooth Wrapper module had the appropriate <code>read_once</code> and <code>write_once</code> functions.

The <code>read_once</code> function internally just called the <code>bt__read</code> function. All of the decodings was done inside the Callback Function.
To get the Destination coordinate the string received from the Android Application was in the form of
<code>$loc,<destination_latitude>,<destination_longitude>.</code>
Upon receiving this data we parsed the destination_latitude and destination_longitude, which could later be accessed using getters.
We also set a start flag to notify the Driver Node that destination has been received and we can start steering towards our checkpoints.

Another command implemented was the stop command.
<code>$stop</code>
This was used to send a stop flag to the Driver node.

The <code>write_once</code> function used the getter methods from each CAN Decode message and update its internal state variables. A CSV String was created using the <code>$canster</code> identifier and various debugging points were appended to this message using a comma.
On the Android application side this CSV string was tokenized and displayed onto the Application Debug screen appropriately.

==== Technical Challenges ====

'''Bluetooth peripheral not turning on'''
* We initially connected the Bluetooth module directly to the SJ-Two board with (Vcc = 3.3v). But it was not giving only 2.7v and hence the device did not turn on.
* We had to connect it to external power source to make it function without hassles.

 

== '''Driver [Driver and LCD Controller]''' ==
'''[https://gitlab.com/coder137/can-ster_truck/-/tree/driver_bleeding_edge_dev GitLab]'''

=== Software Design ===

[[File:CMPE243_S20_T2_Canster Truck_Driver_Flowchart.png|thumb|center|750px|Driver Flowchart]]

The above block diagram explains the process flow of obstacle detection for the car. The LIDAR detects
the obstacle and depending on the distance of obstacle the car takes a slight right and slight left or a
hard right and hard left. The state of the car also depends on the value of the LIDAR and ultrasonic sensor.
The loose ends of the LIDAR for the reverse condition are checked by the ultrasonic sensors. The
The ultrasonic sensor works on the principle of trigger and echo and can detect the obstacles very close by.
The range of the Ultrasonic sensor is lower than the LIDAR. Finally, if no obstacle is detected the car goes
straight until the destination is reached. The speed of the car is also various when an obstacle is detected to
avoid the crash and the car’s smooth transition from one state to another. The key to the android
application controls the start and stop the process of the car. If the key is not pressed, then the stays in the

neutral state. The speed of the car is controlled by the changing duty cycle of the input voltage. There
are seven-speed levels in which the motor can run on. These speed levels are Forward Slow, Medium,
Fast, Reverse Slow, Medium, Fast, and Neutral. The Neutral is the stop condition with a 0% duty cycle.

=== Technical Challenges ===

Technical Challenges faced during obstacle detection:

*Due to dimensions of the car and for the perfect obstacle avoidance the values of 100cm and 150cm had to be selected for the turning radius. Hence, it is very important to calibrate these values appropriately, as these values will be unique for different car designs.
*For a situation, where even if the lidar doesn’t detect any obstacle at the middle, the car must take a slight right or a slight left as per our design. This is the case where the obstacle can be a moving one and that is why the lidar middle couldn’t detect it.

 

== '''LCD [Driver and LCD Controller]''' ==
=== Hardware Design ===
[[File:CMPE243_S20_T2_Canster_Truck_LCD_Diagram.png|thumb|600px|center| LCD Design]]
{|style="text-align: center; width: 400px; height: 200px; margin: auto;"
|
[[File:CMPE243_S20_T2_Canster_Truck_GLCD.jpg|thumb|200px|center| GLCD Hardware]]
||
[[File:CMPE243_S20_T2_Canster_Truck_GLCD2.jpg|thumb|600px|center| GLCD Software Simulation]]
|
|}

=== Software Design ===
The GLCD used was created by 4DSystems, using their IDE a UI was created. Each UI component could be controlled by sending UART data targeted at the widget address.
The best part about this GLCD was that we had a lot of interactive widgets to display debugging information in real-time.
The GLCD code was divided into 3 parts:

=====Low-Level Initialization=====
Initialize the low-level hardware interfaces to send and receive data from the GLCD.
Similar to the GPS and Bluetooth, The UART GPIO was initialized (RX, TX), FreeRTOS Queue was initialized for UART Interrupt and line buffer was used to get a stream of data for parsing.

Low-level '''read''' and '''write''' commands were used as per the working of the GLCD Module.
When Reading data pertaining to a widget on the GLCD we would need to send a particular response packet.

<pre>
void lcd__read(lcd_object_e object_id, uint8_t object_index, uint8_t *response, uint16_t *response_data) {

uint8_t checksum = READ_OBJ ^ object_id ^ object_index;
uint8_t buffer[] = {READ_OBJ, object_id, object_index, checksum};

lcd__write_data(buffer, sizeof(buffer) / sizeof(uint8_t));
lcd__read_response_id(response);
lcd__read_response_data(response_data);
}
</pre>

The response_data returned contains the Widget ID as well as the current value stored on that widget.

When Writing data pertaining to a widget on a GLCD the process is similar to the above mentioned code.
<pre>
void lcd__write(lcd_object_e object_id, uint8_t object_index, uint8_t msb, uint8_t lsb, uint8_t *response) {
uint8_t checksum = WRITE_OBJ ^ object_id ^ object_index ^ msb ^ lsb;
uint8_t buffer[] = {WRITE_OBJ, object_id, object_index, msb, lsb, checksum};

lcd__write_data(buffer, sizeof(buffer) / sizeof(uint8_t));
lcd__read_response_id(response);
}
</pre>

However in this case we receive only an ACK or NACK from the system. ACK would mean that the write to GLCD widget was successful and the widget now stored appropriate values. NACK would mean that a particular error has occurred. The errors could be regarding baud rate, incorrect bit format, incorrect index values, etc.

=====GLCD Wrapper for Widgets=====
The above low-level code had generic read and write functions. However for our UI we were only using 3 Widgets. All of which had '''different Indexes''' and '''Widget IDs'''.
Therefore a very simple library was created to easily interface with those widgets
<pre>
bool lcd_wrapper__read_led(uint8_t index);
uint16_t lcd_wrapper__read_meter(uint8_t index);
uint16_t lcd_wrapper__read_leddigit(uint8_t index);

bool lcd_wrapper__write_led(uint8_t index, bool value);
bool lcd_wrapper__write_meter(uint8_t index, uint16_t value);
bool lcd_wrapper__write_leddigit(uint8_t index, uint16_t value);
</pre>

The above code is self-explanatory read and write functions for '''LED''', '''METER''', and '''LED DIGIT'''.

=====GLCD UI=====
Now that we had our low level and Widget wrapper working properly, we wanted to create our Dynamic UI as well. The code would need to be robust enough to handle any UI that we create on the GLCD which could be reflected equivalently in our C Code.

<pre>
static void lcd_ui__update_ui(void) {

lcd_wrapper__write_led(LCD_LED_DRIVER_MIA_INDEX, driver_mia_led);
lcd_wrapper__write_led(LCD_LED_SENSOR_MIA_INDEX, sensor_mia_led);
lcd_wrapper__write_led(LCD_LED_GEO_MIA_INDEX, geo_mia_led);
lcd_wrapper__write_led(LCD_LED_MOTOR_MIA_INDEX, motor_mia_led);

// kph is always in the range of 0 - 10
lcd_wrapper__write_meter(LCD_METER_KPH_INDEX, kph_meter % 11);

// These will be in the Range of 0-99
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_RPM_INDEX, rpm_leddigit % 100);
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_CURRENTDEGREE_INDEX, cdegree_leddigit % 100);
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_REQUIREDDEGREE_INDEX, rdegree_leddigit % 100);
}
</pre>

As we can see the `lcd_ui__update_ui` function was called periodically inside the 1Hz function. It updated the screen in real time based on the static values that were stored AND updated inside the LCD UI module.
The Constant INDEX values stored were directly mapped onto the Index values were received from the 4DWorkshop UI Software.

=== Technical Challenges ===

*The GLCD needs to be supplied appropriate voltage (5V) at 1A for it to work properly. The LCD does not turn on without an appropriate power supply
*The GLCD UART interface has an additional RES signal. This RES signal resets the GLCD when pulled low. When connecting the UART display it is recommended to always reset the GLCD display for proper working
*The GLCD has a latency of up to 30ms when querying and receiving data. In our case, the real-time system has hard caps on time (i.e up to 1second of delay is possible on the 1Hz function)
*This was rectified by putting the read functions (if any) inside the low priority 1Hz periodic_callback function.
*Write operations do not suffer from such a latency issue since they only send one byte (ACK or NACK) signal back.
*Fortunately most of our logic involved just a write (setting a value on the GLCD) rather than reading or querying the widget.

 

== '''Android Application''' ==
[https://gitlab.com/akhilcherukuri/can-ster_truck_application Gitlab]
=== Software Design ===

<div><ul>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android4.jpg|thumb|none|220px|Info Activity (Top)]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android7.jpg|thumb|none|220px|Info Activity (Middle)]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android5.jpg|thumb|none|220px|Info Activity (Bottom)]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android6.jpg |thumb|none|220px|Debug Activity Screen]]</li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster_Truck_Android_GIF1.gif|thumb|center|220px|App Animations]]</li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster_Truck_Android_GIF2.gif|thumb|center|220px|Live Location]]</li>
</ul></div>
The application consists of a total of 5 Activities:

=====Main Activity=====
**This is the app launch display screen
**It will check for all the required permission onStart().
**Has search button for connecting from a paired device list view
**Once device is clicked, an intent will start the Map Activity
=====Map Activity=====
* For this requirement we are using the Google Maps Fragment, for the map fragment to function we must request an API key from Google and set the key in the manifest of the application.
* Destination marker(Red Marker) is set using <code>setOnMapClickListener</code> to which the car will navigate to, the destination can be changed by clicking elsewhere on the Map Fragment. The marker can be removed using <code>setOnMarkerClickListener</code>.
* When the start button is pressed, the start command identifier along with destination latitude and longitude is sent to the car via the write thread. A background thread is started along with it to indicate the current car's position(Green Marker) along with a plotline between the current position and destination.
* When the stop button is pressed, the stop command identifier is sent to the car, to stop and turn off the car.
=====Info Activity=====
* Messages from Geological, Driver, Motor coming from CAN bus are decoded by the Sensor and Bridge controller and sent to the Android application as a string.
* The received string is parsed and categorizes the data to store it in the required textView to be displayed.
* Bluetooth status, Lidar Values, Ultrasonic Sensor Values, Motor Speed, Motor RPM, Motor PWM, Cars' current location, Compass Heading, Distance till Destination, Checkpoint Index is displayed. This was useful for debugging purposes and allowed us to avoid scanning the mounted LCD or CAN Busmaster on PC during drives.
=====Debug Activity=====
*The main function of this activity is to check all RAW RX and RAW TX messages and create a log of all the data received and sent.
=====Bluetooth Connection Service Activity=====
*This is the background activity that handles all the threads required for transmission and receiving data using Bluetooth connections. It has 3 running threads which is called inside other activities using a handler:
* Accept Thread - Listens to BluetoothServerSocket using listenUsingRfcommWithServiceRecord. In order for the RF communication socket to connect to the HC-05, we used the following <code>UUID: 00001101-0000-1000-8000-00805F9B34FB</code>. This is a generic SSP Bluetooth UUID that enables the socket to directly connected to HC-05 and maintain the connection.
* Connect Thread - Creates a Bluetooth socket using createRfcommSocketToServiceRecord
* Connected Thread - Creates socket.getInputStream(); and socket.getOutputStream(); when bytes are available in input stream it will read them into a buffer.
**All messages for activities are done by <code> Handler mHandler.obtainMessage(); mHandler.sendMessage(); </code>

'''Receieved string:'''
* A String is sent to the Bluetooth app from HC-05 and when it receives a string with identifier "$canster", the message is prased accordingly by using the string delimiter ',' and is ended by the newline character '\n' which will remove the data from StringBuffer.
* <code>Example: $canster,37.339334,-121.881123,37.338713,-121.880685,10.123,20.133,30.123,10.5,88.1,99.2,-2,1,44,7,11,22,33,-3,23\n</code>

'''Manifest:'''
<pre>
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.INTERNET" />
</pre>

'''Dependencies:'''
<pre>
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'com.google.android.gms:play-services-maps:17.0.0'
compile 'com.google.maps.android:android-maps-utils:0.4+'
implementation 'androidx.cardview:cardview:1.0.0'
implementation 'com.google.android.gms:play-services-location:17.0.0'
implementation 'androidx.appcompat:appcompat:1.1.0'
implementation 'androidx.constraintlayout:constraintlayout:1.1.3'
implementation 'com.android.support:design:28.0.0'
implementation 'androidx.navigation:navigation-fragment:2.2.1'
implementation 'androidx.navigation:navigation-ui:2.2.1'
implementation 'androidx.lifecycle:lifecycle-extensions:2.2.0'
</pre>

[[File:CMPE243_S20_T2_BLUETOOTHFLOWCHART.png|thumb|center|650px| Android Application Flowchart]]

=== Technical Challenges ===
*'''Bluetooth Discovery:''' While creating the android application, we were not able to see any Bluetooth devices in the paired device list. The problem was that for the Android versions above Lillipop we would also need location access. We have solved it by writing a function to check whether to check for permissions or not.
<pre>
private void checkBluetoothPermissions() {
Log.d(TAG, "checkBTPermissions: Checking permissions");
int permission_check = this.checkSelfPermission("Manifest.permission.ACCESS_FINE_LOCATION");
permission_check += this.checkSelfPermission("Manifest.permission.ACCESS_COARSE_LOCATION");
if (permission_check != 0) {
this.requestPermissions(new String[]{Manifest.permission.ACCESS_FINE_LOCATION, Manifest.permission.ACCESS_COARSE_LOCATION}, 1001); //Any number
}
else{
Log.d(TAG, "checkBTPermissions: No need to check permissions. SDK version < LOLLIPOP.");
}
}
</pre>
*'''Catching NULL in a StringTokenizer: ''' When sending data using Bluetooth sometimes thee app crashes. Using debug Run log in Android Studio IDE, we have found out that this is because we get <code> NullPointerException, java.util.StringTokenizer </code> error. This is mainly due to passing a null value to the StringTokenizer constructor. This problem can be avoided by after reading a line from the Bluetooth StringBuffer, we check whether it is null, before passing it to the StringTokenizer, but later on, we have preferred to use <code>split();</code> to prase the received string as StringTokenizer is now a legacy class that is retained for compatibility reasons and its use is discouraged in new code.

*'''XML Layouts: ''' Generating layouts is difficult for new android code developers, the design layouts made should be compatible for a wide range of mobile devices but using the new android libraries we have found that, the older phones then tend to have difficulty in showing the layouts correctly. We have solved this problem by learning the design commercial XML design layouts by following tutorials on Udemy and Youtube.

*'''Auto Connect''': During the first stages we have implemented Bluetooth connection via searching for all devices and clicking on the device from Listpair to connect. This has a lot of time to process all the discovered devices near range. To solve this we have hardcoded the HC-05 device address <code>00:14:03:06:02:83</code> to <code>mBluetoothAdapter.getRemoteDevice("device address")</code>.

 

== '''Management''' ==
===Git Management===

Git Management amongst 6 team members was definitely a very challenging task. Depending on our initial design we could’ve had a lot of merge conflicts. However those risks were mitigated by spending a LOT of time in the initial stages to decide our pipeline and structure.

<li>There are certain components in our system that were COMMON. For example the CAN initialization, communication and decodes were all similar for the most part between all the 4 Controllers. The utility modules used were also similar in nature</li>
<li>Thus we made a common branch that contained the templates for CAN Nodes (not Controllers), Hardware code and Utility functions.
<ol>
<li>Later this common branch was forked into an individual Controller specific branch (SENSOR, GEO, MOTOR or DRIVER).</li>
<li>Only the Logic folder contained Controller specific code, specific to that controller.</li>
</ol>
<li>This gave us a lot of flexibility since all the team members had similar APIs to work with on all 4 branches. This promoted easy understanding and learning.
<ol>
<li>Many team members frequently worked on 2 or more controllers at a time where can messages were concerned. Having a APIs also meant that just the can_handler needed to be updated regularly followed by the equivalent logic code. </li>
<li>Inside the logic folder, getters to the can node modules were frequently used.</li></ol>

An example of how one of our initial templates was setup.
<pre>
├───can_module
│ ├───can_bus_initializer
│ ├───can_constants
│ ├───can_driver_node
│ ├───can_geo_node
│ ├───can_handler
│ ├───can_motor_node
│ ├───can_sensor_node
│ └───test
├───hardware
│ ├───bt
│ ├───compass
│ ├───gps
│ ├───lcd
│ ├───lidar
│ ├───motor
│ ├───test
│ └───ultrasonic
├───logic
│ ├───driver_obstacle
│ ├───driver_state
│ ├───geo_logic
│ └───test
└───utility
├───line_buffer
└───test
</pre>

'''Challenges'''
<li>It was initially a bit of a learning curve to understand the flow of the repository</li>
<li>When using a git management system with different versions in each branch it became very tough when the number of branches suddenly exploded in size. A lot of relevant code was stuck in a lot of different branches.
<ol>
<li>This happened mainly due to assignment submissions and unclosed MRs that eventually became stale.</li>
<li>Our strategy was to abandon these MRs and keep forking from these branches without merging it back into its final controller branch.</li>
<li>The latest branches that were kept were aptly named `<controller>_bleeding_edge_dev` branches since they were never merged back from where they were forked.</li>
</ol>
<li>Since a lot of our code also depended on the DBC autogenerated code, we could not suddenly change the DBC Message names once they were established since it caused a change in the Struct name that was generated and used.
<ol>
<li>Our solution to this was to keep everything backward compatible. We added new function names without deleting old DBC messages.</li>
<li>In certain places where we wanted to modify a function name it was done one by one so that a lot of the code is not broken at one time.</li>
</ol>
<li>Common Branches eventually became stale as our progress continued on the bleeding edge branches
<ol>
<li>For example certain GPS features needed to be added which were done on the GEO_bleeding_edge_dev branch but never pushed or cherry-picked back into the COMMON branch.</li>
<li>This was a similar issue to our 2nd point but manageable since the goal of the COMMON branch was to provide a template for further work and nothing more.</li>
<li>At the end of the day each controller is its own Individual Project and while the messages between them are same. The Hardware code does not need to be same.</li>
<li>This also prompted team-members to ask if we could delete unused hardware or logic file code (which wasn’t being used and was imported from the template). This was also fine and can be done during cleanup stage. However we eventually got used to the Modular system of our project so much so that we did not worry about the additional modules that were present in each branched controller project.</li>
</ol>

 

== '''Conclusion''' ==
CMPE243 gives one of the best experiences one could ever get in their academic life. The course is designed to give an insight into how the industry functions and enhances both technical and management skills. Apart from learning how to work and implement application of CAN protocol, one can get a hands-on experience with version control, unit-testing and software design. Overall it was a very great and memorable journey.

=== Project Video ===

=== Project Source Code ===
* [https://gitlab.com/coder137/can-ster_truck GitLab Link]

=== Advise for Future Students ===
'''GENERAL:'''
* Form your team and start the project as early as you can.
* Clearly discuss what role each individual should do and ensure that progress is regularly tracked so that the team doesn't fall back on any schedule.
* Make sure your early structure of the project is decided. Before you start to write the code make sure that all the team and code guidelines are discussed. In our case we spent most of our first week deciding how we wanted to structure and design our code. This paid off in the long run since we had robust code inside one repository that could be extended efficiently.
* Make sure each module is individually testable i.e through periodic callbacks as well as unit-tests. While unit-tests can help for a lot of situations and provide a robust way to map the working of the module, it cannot simulate certain real-life scenarios. For example, Lidar buffer was constantly getting full due to the large number of incoming bytes. This caused us to have certain incorrect reading appear after a few minutes of the lidar running. Our solution was to minimize the <code>printf</code> statements inside the module that were used for debugging.
* Since lot of code and hardware integration is involved with this project, make sure testing is thoroughly and periodically done and make note of all the issues found.
'''HARDWARE:'''
* Decide on how you would power up the peripherals. We had issues with Bluetooth (not connecting), GPS (lock not happening) and LIDAR (giving incorrect values). After lot of cycles of hardware and software debugging, we found that the issue was with power. Choose wisely as to which peripherals must be connected to which power source.
* Isolate the power hungry devices to other parallel connections so that the voltage drop is not high. In our case the Graphical LCD and LIDAR were both very power hungry peripherals. The LCD used to start glitching incase there was a large voltage drop and the LIDAR used to give incorrect values or not update correctly. We solved this issue by giving the lidar a dedicated power supply.
* PCB design involves lot of hardware components. Coordinating with multiple team members and verifying each hardware connection takes quite some time. So start well ahead.
* Make sure to expose some extra GPIO and GND pins for future use.
'''MOTOR:'''
* You can use the LiPo battery to power the RPM and servo motor instead of using a separate power source. Use Vout from the ESC to get 6V.
* Start the PID control calibration early on as you will need to do extensive testing to get it working.

=== Acknowledgement ===
<HR>
Firstly we would like to express our gratitude to Professor Preetpal Kang for his guidance throughout the semester and providing us with this opportunity. We would also like to thank the ISA members Vignesh Kumar Venkateshwar and Aakash Vrajlal Chitroda for being available whenever in need and guiding us to complete the project.

== '''References''' ==
* CAN Reference [https://www.kvaser.com/about-can/can-dictionary/]
* FreeRTOS Reference [http://socialledge.com/sjsu/index.php/FreeRTOS_Tutorial]
* Git tutorial [http://socialledge.com/sjsu/index.php/Basic_Git_Tutorial]
* Unit-test reference [https://gitlab.com/sibros_public/public/-/wikis/c/unit_tests#lab-1]
* Getting started with SJ-Two [https://sjsu-dev2.readthedocs.io/en/latest/getting_started/getting_started/]

===Motor Controller===
* Traxxas User Manual: [https://images-na.ssl-images-amazon.com/images/I/D1NTpa7RNES.pdf]
* Traxxas Specification Sheet: [https://images-na.ssl-images-amazon.com/images/I/81WphBAuwIL.pdf]

===Geological Controller===
* Movable Scripts (Calculate distance, bearing and more between Latitude/Longitude points): [https://www.movable-type.co.uk/scripts/latlong.html]
* CMPS11 (I2C Configuration): [https://www.robot-electronics.co.uk/htm/cmps11i2c.htm]

===Bridge and Sensor Controller===
* [https://www.slamtec.com/en/Lidar/A1 LIDAR]
* [https://components101.com/ultrasonic-sensor-working-pinout-datasheet Ultrasonic sensor ]
===Driver and LCD Controller===
* LCD Software: [https://4dsystems.com.au/ulcd-32ptu 4Dsystems]
===Android===
* Youtube Channel: [https://www.youtube.com/channel/UCoNZZLhPuuRteu02rh7bzsw Coding with Mitch]
* Android Developers: [https://developer.android.com/guide/topics/connectivity/bluetooth Website][https://github.com/googlearchive/android-BluetoothChat Github]
* Udemy Course: [https://www.udemy.com/course/the-complete-android-oreo-developer-course/ Complete Android Oreo Developer Course]
===PCB Design===
* Design Tool: [https://easyeda.com/ EasyEDA]

S20: Canster Truck

2020-05-23T06:36:08Z

Proj user22: /* Advise for Future Students */

[[File:CMPE243_S20_T2_Canster_Truck_Logo.png|thumb|455px|caption|right|CAN-STER TRUCK LOGO]]

== '''Abstract''' ==
The Canster Truck Project is an autonomous RC car with CAN Bus interfaced controllers. The development of the RC car's subsystem modules (Interfacing of Ultrasonic Sensor, LIDAR, Bluetooth, GPS, Compass and CAN modules) was divided among six team members. The aim of the project is to develop an autonomous RC Car which can navigate from one source location to the selected destination on the app by avoiding obstacles in its path using sensors. Waypoints algorithm is used as the path finding technique.
 

== '''Introduction and Objectives''' ==

'''The project was divided into 7 modules:'''

* '''Bridge and Sensor Controller'''
* '''Motor Controller'''
* '''Geological Controller'''
* '''Driver and LCD Controller'''
* '''Hardware Integration'''
* '''Android Application'''
* '''Testing & Code Review'''

'''RC Car Objectives'''
'''1. Driver and LCD Controller''' - Handles algorithms for obstacle avoidance, route maneuvering, and waypoints
'''2. Geological Controller''' - Recieves coordinates from GPS and Heading from Compass for navigation
'''3. Motor Controller''' - Controls movements of the RC Car
'''4. Bridge and Sensor Controller''' - Detects surrounding objects and interfaces android application to controller via bluetooth
'''Team Objectives'''

[[File:CMPE243_S20_T2_High_Level_System_Diagram.png|thumb|center|800px| High Level System Diagram]]

 

== '''Team Members and Responsibilities''' ==
[[File:CMPE243_S20_T2_Canster Truck_Team.jpg|thumb|center|800px| Group Picture]]

'''Gitlab Project Link''' - [https://gitlab.com/coder137/can-ster_truck '''Canster Truck''']
 

*'''Niket Naidu''' [https://www.linkedin.com/in/niket-naidu-30090a134/ LinkedIn] [https://gitlab.com/coder137 Gitlab]
** '''Geological Controller''' : GPS, Compass, Waypoint Algorithm, Haversine and Bearing Angle logic
** '''Driver and LCD Controller''' : GLCD
** '''Bridge and Sensor Controller''' : Bluetooth
** '''Testing & Code Review'''

*'''Ganesh Ram Pamadi''' [https://www.linkedin.com/in/ganeshram93/ LinkedIn] [https://gitlab.com/ganeshram2493 Gitlab]
** '''Hardware Integration'''
** '''Testing & Code Review'''
** '''Driver Controller'''
** '''Motor Controller'''

*'''Nikhil Pabbisetty''' [https://www.linkedin.com/in/nikhilpabbisetty/ LinkedIn] [https://gitlab.com/nikhilpeoria Gitlab]
** '''Bridge and Sensor Controller'''
** '''Motor Controller'''
** '''Driver and LCD Controller'''
** '''Hardware Integration'''

*'''Akhil Cherukuri''' [https://www.linkedin.com/in/akhilcherukuri/ LinkedIn] [https://gitlab.com/akhilcherukuri Gitlab] [https://github.com/akhilcherukuri Github]
** '''Android Application'''
** '''Bridge and Sensor Controller'''

*'''Ashish Anant Ladage''' [https://www.linkedin.com/in/ashish-anant-ladage-7bb3a214b/ LinkedIn] [https://gitlab.com/ashishladage1 Gitlab]
** '''Driver and LCD Controller'''
** '''Hardware Integration'''
** '''Motor Controller'''

*'''Jesus De Haro De Reza''' [https://www.linkedin.com/in/jesus-de-haro-66342424/ LinkedIn] [https://gitlab.com/deharo27 Gitlab]
** '''Bridge and Sensor Controller'''
** '''Motor Controller'''

 

== '''Administrative Responsibilities''' ==
* '''Team Lead''' - [https://www.linkedin.com/in/niket-naidu-30090a134/ '''Niket Naidu''']
* '''Git Repository Manager''' - [https://www.linkedin.com/in/niket-naidu-30090a134/ '''Niket Naidu''']
* '''Bill Of Materials Manager''' - [https://www.linkedin.com/in/akhilcherukuri '''Akhil Cherukuri''']
* '''Wiki Report Manager''' - [https://www.linkedin.com/in/akhilcherukuri '''Akhil Cherukuri''']

 

== '''Schedule''' ==

{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-

! scope="row"| '''1'''
| style="text-align:center;" |'''02/11/2020'''
| style="text-align:center;" |'''02/17/2020'''
|
*'''Form teams and decide group name'''
*'''Review past projects'''
*'''Slack: Create project group and invite Preet'''
*'''GitLab: Create project groups repository'''
*'''Analysis of component required'''

|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''2'''
| style="text-align:center;" |'''02/18/2020'''
| style="text-align:center;" |'''02/24/2020'''
|
*'''Study CAN Communication'''
*'''Create Bill of Materials'''
*'''Order RC Car'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''3'''
| style="text-align:center;" |'''02/25/2020'''
| style="text-align:center;" |'''03/02/2020'''
|
*'''Setup team finance management using Splitwise application'''
*'''Complete Bill of Materials'''
*'''Order all other required components'''
*'''Wikipedia: Setup project report template'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''4'''
| style="text-align:center;" |'''03/03/2020'''
| style="text-align:center;" |'''03/09/2020'''
|
*'''Read the respective datasheets and manuals for each component'''
*'''Test each component for working conditions'''
|
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''5'''
| style="text-align:center;" |'''03/10/2020'''
| style="text-align:center;" |'''03/16/2020'''
|
*'''Assign team responsibilities and roles'''
*'''Setup team project management environment (ClickUp)'''
*'''Define CAN DBC'''
*'''Research GPS antennas and order'''
*'''Android: Environmental setup of Android Studio and enable version control'''
*'''Hardware : Decide PCB editing software (easyEDA)'''
*'''Hardware : Draft schematic for required PCB design'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''6'''
| style="text-align:center;" |'''03/17/2020'''
| style="text-align:center;" |'''03/23/2020'''
|
*'''Hardware : Create model of PCB''' 
*'''Android: Add a Button for changing bluetooth connection status in the application''' 
*'''Geological: Interface Compass module with SJ-2 board using I2C interface''' 
*'''Geological: Interface GPS module with SJ-2 board using the UART interface''' 
*'''Geological: Parse raw data to get meaningful values for GPS and Compass''' 
*'''Sensor: Interface and check the functionality of ultrasonic sensors to the SJ-2 board''' 
*'''Motor: Interface of Servo & DC motor to the SJ-2 board and check for basic functionality''' 
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''7'''
| style="text-align:center;" |'''03/24/2020'''
| style="text-align:center;" |'''03/30/2020'''
|
*'''Hardware : Finalize components placement on PCB.''' 
*'''Motor: Add PWM functionality and test the code on DC and servo motors''' 
*'''Sensor: Interface and check and study the output readings of Lidar sensor with SJ-2 board over UART''' 
*'''LCD Display: Explore UI designing of LCD''' 
*'''Hardware: Finalize on optimal ultrasonic sensor placements''' 
*'''Android: Initiate Bluetooth communication and show staus via text view''' 
*'''Wikipedia: Establish final wiki schedule'''
*'''Complete CAN communication format for each controller and link DBC file to the Wiki'''
*'''Complete high-level system block diagram'''
*'''Complete unit-level block diagrams'''
*'''Bridge: Interface HC-5 bluetooth module with Sj-2 board using serial communicaton'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''8'''
| style="text-align:center;" |'''03/31/2020'''
| style="text-align:center;" |'''04/06/2020'''
|
*'''Hardware: Analyze PCB model and order PCB Circuit board''' 
*'''Android: Initiate Bluetooth communication and send "Hello World".''' 
*'''Wikipedia: Start adding information/images/diagrams to the relevant sections'''
*'''Motor: Configure ESC for correct speed outcome according to frequency & PWM values''' 
*'''Motor: Finish RPM sensor hardware and software implementation and integration''' 
*'''Sensor: Read output from Lidar and setup structure for outputting for DBC''' 
*'''Geological: Implement waypoints algorithm''' 
*'''Driver: Implement obstacle avoidance algorithm''' 
*'''Bridge: Pass data such as "Hello World" from HC-05 bluetooth module to bluetooth terminal android application'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''9'''
| style="text-align:center;" |'''04/07/2020'''
| style="text-align:center;" |'''04/13/2020'''
|
*'''Hardware: Remove Unused parts from RC Car''' 
*'''Hardware: Mount PCB and 3D Parts''' 
*'''Motor: Decide different cut-off values from sensor to command right /slight right/ straight/ slight left/ left to motor.''' 
*'''Android: Embed Google Maps API for setting the car's destination.''' 
*'''LCD: Work to show RC cars live status information(battery level, current speed, long, lat, bearing, sensor data, etc)''' 
*'''Driver: Test obstacle avoidance algorithm and fine-tune sensor readings''' 
*'''Geological: Test checkpoint algorithm''' 
*'''Bridge: Establish two way communication between android application and bluetooth module''' 
*'''Update Bill of Materials for miscellaneous hardware'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''10'''
| style="text-align:center;" |'''04/14/2020'''
| style="text-align:center;" |'''04/20/2020'''
|
*'''Hardware: Integrate all hardware modules''' 
*'''LCD: Testing & Validation of the LCD UI and display vehicle status information''' 
*'''Android: Send car location to the app and checkpoints received to Geo module''' 
*'''Motor: Optimize PID control by accelerating/decelerating as instructed by Driver''' 
*'''Bridge: Configure HC-05 for auto reconnection if bluetooth communication disconnects''' 
*'''Add multiple debug messages and transmit on CAN'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''11'''
| style="text-align:center;" |'''04/21/2020'''
| style="text-align:center;" |'''04/27/2020'''
|
*'''Android: Send additional vehicle status information from RC car to the Application for display''' 
*'''Android: Finalize User Interface Design and Icon''' 
*'''Continuously test the whole system and handling of corner cases (outside).'''
*'''Finalize RC Car For Project Proto 1'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''12'''
| style="text-align:center;" |'''04/28/2020'''
| style="text-align:center;" |'''05/04/2020'''
|
*'''Gitlab: Push final code'''
*April 28th: Project Proto 1
*'''Finalize RC Car for Project Demo'''
*May 1st: Project Presentation
*'''Finalize RC Car for Project Proto 2'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''13'''
| style="text-align:center;" |'''05/05/2020'''
| style="text-align:center;" |'''05/21/2020'''
|
* '''Complete Individual Contribution Peer Grading'''
* '''Review and Complete Wiki Project Page'''
|
*'''Completed'''
*'''Completed'''
|-
|}

 

== '''Bill Of Materials''' ==
{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Item#
! scope="col"| Part Description
! scope="col"| Part Model & Vendor
! scope="col"| Quantity
! scope="col"| Cost in USD
|-
! scope="row"| 1
| '''Microcontroller Boards'''
| SJ2 Boards (Purchased from Preet Kang)
| 4
| $200.00
|-
! scope="row"| 2
| '''CAN Transceivers'''
| [https://www.waveshare.com/sn65hvd230-can-board.htm Waveshare SN65HVD230]
| 12
| $54.48
|-
! scope="row"| 3
| '''RC Car'''
| [https://www.amazon.com/Traxxas-Slash-Course-2-4GHZ-Vehicle/dp/B01DU474B0/ref=sr_1_3?ie=UTF8&qid=1474747759&sr=8-3&keywords=Traxxas+1%2F10+slash+2wd Traxxas 2WD RTR with 2.4Ghz Radio]
| 1
| $260.00
|-
! scope="row"| 4
| '''Lithium-Ion Battery'''
| [https://www.rcsuperstore.com/traxxas-7600mah-2s-7-4v-25c-id-lipo-battery-pack/ Traxxas 7600mAh 2S 7.4V 25C iD LiPo Battery Pack]
| 1
| $75.00
|-
! scope="row"| 5
| '''Lithium-Ion Battery Charger'''
| [https://www.amazon.com/Traxxas-2970-EZ-Peak-Charger-Identification/dp/B00OAFYLJC/ref=pd_bxgy_21_img_2?ie=UTF8&psc=1&refRID=JVX791WVV9Y8T9DW92KW Traxxas 2970 EZ-Peak Plus 4-Amp NiMH/LiPo Fast Charger]
| 1
| $50.00
|-
! scope="row"| 6
| '''Compass Breakout Board'''
| [https://www.dfrobot.com/product-1275.html DFRobot CMPS11 Compass]
| 1
| $29.99
|-
! scope="row"| 7
| '''Bluetooth Breakout Board'''
| [https://www.amazon.com/HC-05-Bluetooth-Pass-through-Wireless-Communication/dp/B01G9KSAF6/ref=sr_1_4?ie=UTF8&qid=1507077325&sr=8-4&keywords=arduino+bluetooth+hc-05 DSD TECH Bluetooth HC-05]
| 1
| $8.49
|-
! scope="row"| 8
| '''LIDAR Sensor'''
| [https://www.amazon.com/RPLiDAR-A1M8-Degree-Laser-Scanner/dp/B07H7X3SFF/ref=sr_1_fkmrnull_1?crid=2FSUI76G4UA8K&keywords=rplidar+a1m8+-+360+degree+laser+scanner+development+kit&qid=1552764172&s=gateway&sprefix=RPlidar%2Caps%2C263&sr=8-1-fkmrnull SEEED STUDIO RPLIDAR A1M8]
| 1
| $109.99
|-
! scope="row"| 9
| '''RPM Sensor'''
| [https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM Traxxas 6520 RPM Sensor]
| 1
| $13.70
|-
! scope="row"| 10
| '''GPS Breakout Board'''
| [https://www.adafruit.com/product/746 Adafruit Ultimate GPS Breakout v3]
| 1
| $44.30
|-
! scope="row"| 11
| '''LCD Display'''
| [https://4dsystems.com.au/ulcd-32ptu 4Dsystems 3.2 TFT-LCD ULCD-32PTU]
| 1
| $79.00
|-
! scope="row"| 12
| '''Ultrasonic Sensors'''
| [https://www.amazon.com/gp/product/B01COSN7O6/ ELEGOO HC-SR04 Ultrasonic Module]
| 5
| $12.00
|-
! scope="row"| 13
| '''GPS Antenna'''
| [https://www.amazon.com/dp/B07RRT615K/ GPS Antenna A1-UX]
| 1
| $10.98
|-
! scope="row"| 14
| '''PCB Fabrication'''
| [https://jlcpcb.com/ JLCPCB]
| 5
| $40.15
|-
! scope="row"| 15
| '''Miscellaneous'''
| [https://www.amazon.com Amazon],[https://www.mouser.com/ Mouser Electronics],[https://www.digikey.com/ Digikey],[https://anchor-electronics.com/ Anchor Electronics]
| ~
| $48.07
|-
! scope="row"|
|
|
| '''Total'''
| '''$1036.15'''
|-

|}

 

== '''Printed Circuit Board''' ==

=== Design And Architecture ===
The complete PCB (for boards and hardware peripherals) was designed using EasyEDA online software. The 4 nodes will be communicating via CAN bus and other peripherals are connected to the PCB via headers.

=== Power Section===
We have 2 power banks supplying our system. And the Servo Motor, RPM sensor and DC rear Motor (via ESC) are powered using LiPo battery (6 volts).
* Power bank #1 - Subset 2

* Power bank #2 - Subset 1, Subset 3, Bluetooth Module

'''NOTE:'''

'''Subset 1:'''
1. LIDAR
2. LCD
3. Compass

'''Subset 2:'''
1. Motor node
2. Driver node
3. BS node

'''Subset 3:'''
1. Geo node
2. Back ultrasonic sensor

=== Fabrication ===
* PCB was sent to fabrication to JLCPCB China which provided PCB with MOQ of 5 and 2 layers of PCB and common grounded the rest of the copper area.
'''DRC elements (in mils)'''
* Track Width = 12
* Clearance = 10
* Via Diameter = 24
* Via Drill Diameter = 12

=== Challenges ===
* Auto-routing gave lot of challenges (only ~60% success) and sometimes the online server even crashes and faces downtime. Even local routing had lot of issues. So make sure to plan your design accordingly.
* We started our PCB design well ahead of the project. So lot of pre-planning had to be done with regard to final hardware and placement of components in order to avoid spending extra time and money while re-ordering.
* The PCB went through a lot of internal revisions even before placing order. This was time-consuming.

'''Other hardware challenges:'''
* Figuring out why various hardware peripherals (GPS, Bluetooth, LIDAR and Ultrasonic sensor) started to malfunction (devices were on but values were either inconsistent / not occurring), took a lot of time to debug. It was due to insufficient power.

 
[[File:CMPE243 S20 T2 EasyEDA.png|1040x1200px|thumb|center|PCB Layout Design in EasyEDA]]
 
[[File:CMPE243 S20 T2 PCB SCHEMATIC.jpg|1041x550px|thumb|center|PCB Schematic]]
 
[[File:CMPE243 S20 T2 PCBFRONT.jpg|thumb|center|600px|PCB Top Layer]]
 
[[File:CMPE243 S20 T2 PCBBACK.jpg|thumb|center|600px|PCB Bottom Layer]]

 

== '''CAN Communication''' ==

=== Hardware Design ===
[[File:CMPE243_S20_T2_Canster_Truck_CANHW.png|thumb|center|770px| CAN Hardware Diagram]]

=== DBC File ===

DBC FILE: [https://gitlab.com/coder137/can-ster_truck/-/blob/dbc-improvements/projects/lpc40xx_freertos/project.dbc Gitlab]

<pre>
VERSION ""

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

BS_:

BU_: DBG DRIVER IO MOTOR SENSOR GEO

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" GEO,MOTOR,SENSOR

BO_ 101 GEO_HEARTBEAT: 1 GEO
SG_ GEO_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,MOTOR,SENSOR

BO_ 102 MOTOR_HEARTBEAT: 1 MOTOR
SG_ MOTOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,SENSOR

BO_ 103 SENSOR_HEARTBEAT: 1 SENSOR
SG_ SENSOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,MOTOR

BO_ 200 MOTOR_STEERING: 1 DRIVER
SG_ MOTOR_STEERING_direction: 0|8@1- (1,0) [-2|2] "" MOTOR

BO_ 210 DRIVER_COORDINATES: 8 DRIVER
SG_ DRIVER_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
SG_ DRIVER_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 220 MOTOR_SPEED: 1 DRIVER
SG_ MOTOR_SPEED_processed: 0|8@1- (1,0) [-3|3] "" MOTOR

BO_ 300 GEO_DEGREE: 8 GEO
SG_ GEO_DEGREE_current: 0|32@1+ (0.000001,0) [0|360] "degrees" DRIVER
SG_ GEO_DEGREE_required: 32|32@1+ (0.000001,0) [0|360] "degrees" DRIVER

BO_ 310 GEO_DESTINATION_REACHED: 1 GEO
SG_ GEO_DESTINATION_REACHED_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 400 MOTOR_SPEED_FEEDBACK: 4 MOTOR
SG_ MOTOR_SPEED_current: 0|32@1+ (0.1,0) [0|60] "kph" DRIVER

BO_ 500 SENSOR_BT_COORDINATES: 8 SENSOR
SG_ SENSOR_BT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
SG_ SENSOR_BT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 510 SENSOR_SONARS: 8 SENSOR
SG_ SENSOR_SONARS_left: 0|21@1+ (0.001,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right: 21|21@1+ (0.001,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle: 42|21@1+ (0.001,0) [0|0] "cm" DRIVER

BO_ 520 SENSOR_LIDAR: 8 SENSOR
SG_ SENSOR_LIDAR_middle: 0|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_slight_left: 16|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_slight_right: 32|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_back: 48|16@1+ (1,0) [0|0] "cm" DRIVER

BO_ 530 MOTOR_KEY: 1 SENSOR
SG_ MOTOR_KEY_val: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 900 GEO_CURRENT_COORDINATES: 8 GEO
SG_ GEO_CURRENT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" DBG
SG_ GEO_CURRENT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" DBG

BO_ 901 GEO_DISTANCE_FROM_DESTINATION: 4 GEO
SG_ GEO_distance_from_destination: 0|32@1+ (0.001,0) [0|0] "meters" DBG

BO_ 902 MOTOR_INFO_DBG: 4 MOTOR
SG_ MOTOR_INFO_DBG_rps: 0|16@1+ (1,0) [0|0] "" DBG
SG_ MOTOR_INFO_DBG_pwm: 16|16@1+ (0.001,0) [0|0] "" DBG

BO_ 903 LIPO_BATTERY_VOLTAGE_DBG: 4 MOTOR
SG_ LIPO_BATTERY_VOLTAGE_val: 0|32@1+ (0.01,0) [0|0] "volts" DBG

BO_ 904 CURRENT_CHECKPOINT_DBG: 1 GEO
SG_ CURRENT_CHECKPOINT_val: 0|8@1+ (1,0) [0|0] "" DBG

CM_ "--BU (Network Node) Information--";
CM_ BU_ DRIVER "The driver controller of the car";
CM_ BU_ GEO "The geo controller of the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";

CM_ "--BO (Message) Information--";
CM_ BO_ 100 "Driver Sync message used to synchronize the controllers";
CM_ BO_ 101 "Geo Sync message used to synchronize the controllers";
CM_ BO_ 102 "Motor Sync message used to synchronize the controllers";
CM_ BO_ 103 "Sensor Sync message used to synchronize the controllers";

CM_ BO_ 200 "Steering direction values sent by Driver Node to Motor Node";
CM_ BO_ 210 "Driver Destination coordinates sent by Driver Node";
CM_ BO_ 220 "Required motor speed computed from Driver Node to Motor Node";

CM_ BO_ 300 "Current and computer/required degree values sent by Geo Node";
CM_ BO_ 310 "Indicator signal to check if the RC car has reached the destination";

CM_ BO_ 400 "Current motor info (rps and kph) sent as feedback to the Driver Node";

CM_ BO_ 500 "Coordinate BT values (destination coordinates) sent by Sensor Node";
CM_ BO_ 510 "LIDAR - Distance from obstacle detected in each sector";
CM_ BO_ 520 "Ultrasonic Sensor - Distance from obstacle detected by each sensor";
CM_ BO_ 530 "Start/Stop signal from the Bluetooth app";

CM_ BO_ 900 "Destination coordinates for BUSMASTER debugging";
CM_ BO_ 901 "Distance from destination";
CM_ BO_ 902 "Supplied PWM value to the motor and its RPM";
CM_ BO_ 903 "LIPO Battery Voltage";
CM_ BO_ 904 "Current checkpoint of the car";

CM_ "--SG (Signal) Information for Heartbeats--";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver node";
CM_ SG_ 101 GEO_HEARTBEAT_cmd "Heartbeat command from the geological node";
CM_ SG_ 102 MOTOR_HEARTBEAT_cmd "Heartbeat command from the motor node";
CM_ SG_ 103 SENSOR_HEARTBEAT_cmd "Heartbeat command from the sensor node";

CM_ "--SG (Signal) Information for DRIVER Node--";
CM_ SG_ 200 DRIVER_STEERING_direction "Calculated Driver Steering values (-2,2) for Motor";
CM_ SG_ 210 DRIVER_COORDINATES_latitude "Destination Latitude coordinate";
CM_ SG_ 210 DRIVER_COORDINATES_longitude "Destination Longitude coordinate";
CM_ SG_ 220 MOTOR_SPEED "Calculated Driver speed values (-3,3) for Motor";

CM_ "--SG (Signal) Information for GEO Node--";
CM_ SG_ 300 GEO_DEGREE_current "Current Geo Degree relative to true north";
CM_ SG_ 300 GEO_DEGREE_required "Calculated Geo Degree computed by Haversine Formula";
CM_ SG_ 310 GEO_DESTINATION_REACHED "Indicator signal to check if the RC car has reached the destination";

CM_ "--SG (Signal) Information for MOTOR Node--";
CM_ SG_ 400 MOTOR_SPEED_FEEDBACK "Feedback speed (kph) sent by Motor Node";

CM_ "--SG (Signal) Information for SENSOR Node--";
CM_ SG_ 500 SENSOR_BT_COORDINATES_latitude "Destination Latitude received over Bluetooth";
CM_ SG_ 500 SENSOR_BT_COORDINATES_longitude "Destination Longitude received over Bluetooth";
CM_ SG_ 510 SENSOR_SONARS_left "Ultrasonic Sensor attached to the left side";
CM_ SG_ 510 SENSOR_SONARS_right "Ultrasonic Sensor attached to the right side";
CM_ SG_ 510 SENSOR_SONARS_middle "Ultrasonic Sensor attached to the middle";
CM_ SG_ 510 SENSOR_SONARS_back_left "Ultrasonic Sensor attached to the back left side";
CM_ SG_ 510 SENSOR_SONARS_back_right "Ultrasonic Sensor attached to the back right side";
CM_ SG_ 520 SENSOR_LIDAR_middle "Lidar sensing the middle sector (-15 to 15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_left "Lidar sensing the slight left sector (-45 to -15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_right "Lidar sensing the slight right sector (15 to 45 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_back "Lidar sensing the back of the car (165 to 195 degrees)";
CM_ SG_ 530 MOTOR_KEY_val "1 -> Start the motor from the app, 0 -> Stop";

CM_ SG_ 900 GEO_CURRENT_COORDINATES_latitude "Current Latitude";
CM_ SG_ 900 GEO_CURRENT_COORDINATES_longitude "Current Longitude";
CM_ SG_ 901 GEO_distance_from_destination "Distance from destination";
CM_ SG_ 902 MOTOR_INFO_DBG_rps "Current RPS value of the motor";
CM_ SG_ 902 MOTOR_INFO_DBG_pwm "Supplied motor PWM value";
CM_ SG_ 903 LIPO_BATTERY_VOLTAGE_val "LIPO Battery Voltage";
CM_ SG_ 904 CURRENT_CHECKPOINT_val "Current checkpoint of the car";

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

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

BA_ "GenMsgCycleTime" BO_ 100 1000;
BA_ "GenMsgCycleTime" BO_ 200 50;
BA_ "FieldType" SG_ 100 DRIVER_HEARTBEAT_cmd "DRIVER_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 102 GEO_HEARTBEAT_cmd "GEO_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 103 MOTOR_HEARTBEAT_cmd "MOTOR_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 104 SENSOR_HEARTBEAT_cmd "SENSOR_HEARTBEAT_cmd";

BA_ "FieldType" SG_ 200 MOTOR_STEERING "MOTOR_STEERING";
BA_ "FieldType" SG_ 230 MOTOR_SPEED_val "MOTOR_SPEED_val";
BA_ "FieldType" SG_ 310 GEO_DESTINATION_REACHED_cmd "GEO_DESTINATION_REACHED_cmd";

VAL_ 100 DRIVER_HEARTBEAT_cmd 2 "DRIVER_HEARTBEAT_cmd_REBOOT" 1 "DRIVER_HEARTBEAT_cmd_SYNC" 0 "DRIVER_HEARTBEAT_cmd_NOOP" ;
VAL_ 101 GEO_HEARTBEAT_cmd 2 "GEO_HEARTBEAT_cmd_REBOOT" 1 "GEO_HEARTBEAT_cmd_SYNC" 0 "GEO_HEARTBEAT_cmd_NOOP";
VAL_ 102 MOTOR_HEARTBEAT_cmd 20 "MOTOR_HEARTBEAT_cmd_REBOOT" 10 "MOTOR_HEARTBEAT_cmd_SYNC" 0 "MOTOR_HEARTBEAT_cmd_NOOP" ;
VAL_ 103 SENSOR_HEARTBEAT_cmd 200 "SENSOR_HEARTBEAT_cmd_REBOOT" 100 "SENSOR_HEARTBEAT_cmd_SYNC" 0 "SENSOR_HEARTBEAT_cmd_NOOP" ;

VAL_ 200 MOTOR_STEERING_direction -2 "MOTOR_STEERING_hard_left" -1 "MOTOR_STEERING_slight_left" 0 "MOTOR_STEERING_straight" 1 "MOTOR_STEERING_slight_right" 2 "MOTOR_STEERING_hard_right";
VAL_ 220 MOTOR_SPEED_processed -3 "MOTOR_SPEED_reverse_fast" -2 "MOTOR_SPEED_reverse_medium" -1 "MOTOR_SPEED_reverse_slow" 0 "MOTOR_SPEED_neutral" 1 "MOTOR_SPEED_forward_slow" 2 "MOTOR_SPEED_forward_medium" 3 "MOTOR_SPEED_forward_fast";
VAL_ 310 GEO_DESTINATION_REACHED_cmd 1 "GEO_DESTINATION_REACHED_cmd_REACHED" 0 "GEO_DESTINATION_REACHED_cmd_NOT_REACHED";
</pre>

 

== '''Motor Controller''' ==
'''[https://gitlab.com/coder137/can-ster_truck/-/tree/motor_bleeding_edge_dev GitLab Link]'''

This controller is used to control the components of the car-related to motor. We can control the speed and steering of the car having interfaced with various components with the SJ-2 board. The servo motor is controlled via PWM and is used to set the steering direction of the car. The DC motor is controlled by the Electronic Speed Controller (ESC) via PWM for speed. We read the speed of the car by using an RPM sensor. By using the RPM sensor values, a feedback loop has been designed to regulate the speed of the car. A state machine has been designed to manage the forward and backward movements of the car.
Additionally, a voltage divider circuit has been implemented to read the battery voltage. All motor functionality and CAN message communication is run at 10 Hz.

=== Hardware Design ===

[[File:CMPE243_S20_T2_Canster_Truck_Motor_Hardware.png|thumb|center|750px| Motor Hardware System]]

The following diagram details the hardware implementation of the motor module with the SJTwo board:
Hardware Interface
=====Servo Motor=====
The servo motor responds to PWM pulses. It has three pins namely Vcc, PWM Input Signal, and GND. The servo is powered using 6V from the car battery. Based on the PWM signal supplied from the SJTwo board the front wheels are turned.
[[File:CMPE243_S20_T2_Canster_Truck_Motor_1.jpg|440px|thumb|center|| Servo Motor]]
{| class="wikitable" style="text-align: center; width: 400px; height: 200px; margin: left;"
|+ Servo Motor Pin Connection
|-
! Sr. No.
! Wires - Servo Motor
! Function
|-
! 1
| PWM Connected to P2.5 || PWM Signal from Sj-2 Board
|-
! 2
| VCC || 6V supply from ESC
|-
! 3
| GND || Common Ground
|-
|}

=====Electronic Speed Controller (ESC)=====
The ESC is used to control the DC motor. It is supplied power using the 7.4 V LiPo battery. It has three pins namely Vout, PWM Input Signal, and GND. Based on the PWM input signal, the speed and forward, neutral, and backward movements of the car is changed. Vout is given to the RPM sensor and Servo motor.
[[File:CMPE243_S20_T2_Canster_Truck_Motor_2.jpg|440px|thumb|center|| Electronic Speed Controller (ESC)]]
{| class="wikitable" style="text-align: center; width: 400px; height: 200px; margin: left;"
|+ Speed Sensor Pin Connection
|-
! Sr. No.
! Wires - RPM Sensor
! Function
|-
! 1
| Signal Wire Connected to P2.0 || GPIO that supplies pulses to controller
|-
! 2
| VCC || 6V supply from ESC
|-
! 3
| GND || Common Ground
|-
|}

=====DC Motor=====
The DC motor is controlled using the ESC. It has two pins, a positive and a negative terminal. A PWM signal wire is connected to the microcontroller and the required current is provided by the LiPo battery and the ESC. The DC motor is controlled using PWM at 10Hz.

[[File:CMPE243_S20_T2_Canster_Truck_Motor_3.jpg|320px|thumb|center|| DC Motor]]
{|
|-
|
{| class="wikitable" style="text-align: center; width: 400px; height: 200px; margin-left:0px;"
|+ DC Motor Pin Connection
|-
! Sr. No.
! Wires - DC Motor
! Description
|-
! 1
| Positive Wire (already connected) || Positive Terminal
|-
! 2
| Negative Wire (already connected || Negative Terminal
|-
|}
 
{| class="wikitable" style="text-align: center; width: 400px; height: 200px;"
|+ DC Motor Configuration
|-
! Operation
! Pulse Width Range (ms)
! Duty Cycle(%)
|-
! FORWARD
| 1.51 - 2.00 || 15.1-20.0
|-
! STOP
| 1.50 || 15.0
|-
! REVERSE
| 1.00 - 1.49 || 10.0-14.9
|-
|}
|
|-
|}

Note: First calibrate the DC motor or the motor will not respond to your PWM pulses. For help with calibration go to this [https://traxxas.com/support/Programming-Your-Traxxas-Electronic-Speed-Control website]

=====RPM Sensor=====

The RPM sensor is used to get the current speed of the car. We use the info for creating a feedback loop (PID) for maintaining the speed of the car in uphill and downhill situations. The RPM sensor mounts on the rear DC motor shaft compartment with a special assembly also provided by Traxxas. The magnet which attached to the inner gear generates a pulse each rotation. The sensor works on the hall effect principle where it provides a current across its terminal when placed in a magnet's field. The RPM sensor has three pins namely Vcc, Signal, and GND.

[[File:CMPE243_S20_T2_Canster_Truck_Motor_4.jpg|440px|thumb|center|| RPM Sensor]]

{| class="wikitable" style="text-align: center; width: 400px; height: 200px; margin: left;"
|+ Speed Sensor Pin Connection
|-
! Sr. No.
! Wires - RPM Sensor
! Function
|-
! 1
| Signal Wire Connected to P2.2 || GPIO that supplies pulses to controller
|-
! 2
| VCC || 6V supply from ESC
|-
! 3
| GND || Common Ground
|-
|}

=== Software Design ===

The software for the motor node was divided into multiple files and made modular to improve readability and understanding of the complex logic involved. The main code modules are for:
*Servo Motor
*Electronic Speed Controller
*RPM Sensor
*Motor Wrapper
*Battery Voltage

The motor wrapper module is used to wrap all the code from the esc, servo, and rpm modules into simple to use functions to be called in the periodic tasks.
=====Servo Motor=====
It uses the steering value sent from the driver (-2 to 2) and matches it to the appropriate PWM value for steering. This code module is run at 10Hz.
<pre>
void servo__steer_processor(int16_t steering_value) {
switch (steering_value) {
case MOTOR_STEERING_hard_left:
servo__steer_hard_left();
break;
case MOTOR_STEERING_slight_left:
servo__steer_soft_left();
break;
case MOTOR_STEERING_straight:
servo__steer_straight();
break;
case MOTOR_STEERING_slight_right:
servo__steer_soft_right();
break;
case MOTOR_STEERING_hard_right:
servo__steer_hard_right();
break;
default:
printf("\nDid not receive steering value");
}
}
</pre>
=====Electronic Speed Controller=====

This code module is used to control the DC motor. It receives the motor direction value from the driver and sets the appropriate PWM value. Based on the value the motor is commanded to move the car forward or backwards. A switch case is implemented to set PWM values for movement in different directions along with different speeds.
<pre>
void esc__direction_processor(int16_t direction_value) {
desired_direction_value = direction_value;
switch (direction_value) {
case MOTOR_SPEED_reverse_fast:
esc__reverse_fast();
break;
case MOTOR_SPEED_reverse_medium:
esc__reverse_medium();
break;
case MOTOR_SPEED_reverse_slow:
esc__reverse_slow();
break;
case MOTOR_SPEED_neutral:
esc__neutral();
break;
case MOTOR_SPEED_forward_slow:
esc__forward_slow();
break;
case MOTOR_SPEED_forward_medium:
esc__forward_medium();
break;
case MOTOR_SPEED_forward_fast:
esc__forward_fast();
break;

default:
printf("\nDid not receive direction and speed value");
}
}
</pre>

There is also a feedback loop to control the speed. The ESC code depends on the rpm sensor code for the current speed values.
<pre>
double current_speed = get_speed_kph();
double desired_speed = desired_speed_kph;
float adjusted_duty_cycle = 0.0;
adjusted_duty_cycle = duty_cycle + (speed_to_pwm_adjustment(desired_speed, current_speed));
</pre>

[[File:CMPE243_S20_T2_Canster_Truck_Motor1.png|thumb|center|500px| Feedback Loop for Motor Speed]]

=====RPM Sensor=====
This code module is used to get current speed data from the RPM sensor. It is based on interrupts. When the wheel rotates once, we get one pulse due to the magnet installed. This pulse generates a falling edge interrupt during which we increment the pulse counter. Since, this code is run at 1Hz we collect the number of pulses generated every one second. This gives us the number of rotations per second using which we can calculate the speed in kph.
<pre>
float rpm__calculate_speed_kph() {
uint16_t rotation_per_sec = pulse_count;
pulse_count = 0;
speed_kph = ((CIRCUMFERENCE_METER * rotation_per_sec) * (MPS_TO_KPH_CONVERSION_FACTOR)) / GEAR_RATIO;
return speed_kph;
}
</pre>

=====Motor Wrapper=====
As mentioned above, the main function of this code module is to wrap all the other code modules and call the right functions at the appropriate frequency. The motor wrapper code also includes a state machine for ensuring a smooth transition between forward to backward state and vice versa. In order to achieve a smooth transition, a series of PWM pulses must be generated at the right time. For example, when the motor is moving from forward to backward state, a reverse value must be given first followed by at least three neutral values, and then continue with reverse values.

[[File:CMPE243_S20_T2_Canster_Truck_Motor2.png|thumb|center|500px| State Machine Flowchart for Motor Movements]]

=====LiPo Battery Voltage=====

The LiPo Battery Voltage was calculated using ADC in Burst Mode. A LiPo Hardware module was created for the same which contained two functions, <code>lipo__init</code> and <code>lipo__get_voltage</code>.

The voltage divider circuit is stepped down from 7.4V to 2.1V using 10K and 4K Resistor pair.
[[File:CMPE243_S20_T2_Canster Truck_Motor_Voltage_Regulator.png|thumb|center|400px| Voltage Regulator]]
'''LiPo Initialization'''

The LiPo Initialization phase initializes the ADC, Enables Burst mode on the ADC pins and configures the Alternate Function Registers for the same.

'''Getting LiPo Voltage'''

We read the raw ADC value from the LPC Hardware register. This value will be from 0 - 3.3V. However due to our voltage divider configuration the max voltage that we should theoretically get is 2.1V. This means that 2.1V corresponds to 7.4V of the LIPO Battery voltage.

The formula used is
<code>(raw_adc_value * MAX_LIPO_BATTERY_VOLTAGE_VALUE) / MAX_LIPO_ADC_VALUE</code>

=== Technical Challenges ===
<li>Changing movements of the car from Forward to Backward and vice versa
If you just change the PWM value from say 16 (Forward) to 14(Backward), the DC motor will just stop and will not make wheels turn reverse. We discovered this problem quite late as during the initial testing we had always run the car from the start with either forward or reverse but never tried changing the direction during run-time.
 
Solution: The motor requires a series of PWM pulses which is specific to the car to transition from forward mode to reverse mode. In our case we had to give the PWM pulses in the following sequence. Suppose,
<ol>
<li> Forward (16) (callback_count = 0)</li>
<li> Forward (16) (callback_count = 1)</li>
<li> Reverse (14) (callback_count = 2)</li>
<li> Neutral (15) (callback_count = 3)</li>
<li> Neutral (15) (callback_count = 4)</li>
<li> Neutral (15) (callback_count = 5)</li>
<li> Reverse (14) (callback_count = 6)</li>
<li> Continue reverse</li>
</ol>
Similarly, the reverse to forward can also be implemented.
<li>DC motor shooting off when there is an improper ground connection
When we connected the battery voltage circuit for reading the voltage from the battery, the motor would randomly shoot off every now and then.
 
Solution: Connect the voltage divider circuit to the common ground rather than taking the ground from the ESC.</li>

 

== '''Geological Controller''' ==
'''[https://gitlab.com/coder137/can-ster_truck/-/tree/geo_bleeding_edge_dev_waypoints GitLab Link]'''

===Messages===
*GEO_HEARTBEAT: Used to check for MIA by other nodes. Highest priority message for GEO Node

*GEO_DEGREE: Sends the current degree relative to the North Pole computed by the Compass and the Required degree relative to the North Pole computed by Bearing Angle using the Current Coordinate and Destination Coordinate.

*GEO_DESTINATION_REACHED: Sets a flag, 0 for destination not reached and 1 for destination reached

*GEO_CURRENT_COORDINATES: Debug Message used to send the Current GPS Coordinates

*GEO_DISTANCE_FROM_DESTINATION: Debug message used to send the Distance from Destination

*CURRENT_CHECKPOINT_DBG: Debug message used to check which checkpoint is being navigated to

=== Hardware Design ===

[[File:CMPE243_S20_T2_GEO1.png|thumb|center|650px| Geological Diagram]]

=== Software Design ===
=====Overview=====
*Inside the `periodic_callback__initialize`
**Initialize the CAN BUS
**Initialize the GPS

*Inside the `periodic_callback__1hz`
**Handle all MIA (from other Nodes)
**Update GPS LED when init and in case of failure
**Compute the GEO logic for Waypoints algorithm once every second (1000 ms)

*Inside the `periodic_callback__10hz`
**Handle CAN Incoming messages (Decode)
**Transmit CAN Geo messages (Encode and send)
**Compute the GPS Coordinate

=====Compass I2C Driver=====
An online datasheet resource was used to work with the Compass ([https://www.robot-electronics.co.uk/htm/cmps11i2c.htm CMPS11 Datasheet])
Initially the Compass I2C Driver was tested using the Terminal I2C Helper built by our Professor Preetpal Kang. Using this resource we were quickly able to read various I2C Registers and display it onto the terminal.

For our project the only required part of the Compass was the 16-bit Compass Bearing value (0-3599) i.e 0-359.9 degree values. These values were stored in the 2nd and 3rd register (Register 2 being the High Byte).
Once the raw data was received over I2C we could easily combine the data

<pre>
uint16_t bearing_value = (Reg2 << 8) | Reg3;
float rval = bearing_value / 10.0;
return rval;
</pre>
The returned value were transmitted to the Driver Node to compute its steering based on the required Bearing Angle.

=====GPS Initialization=====
GPS Initialization activates the Hardware GPIO (RX and TX), FreeRTOS Queue for UART Interrupts (UART Module) and Line Buffer Module to parse each GPS line.

=====GPS Data Parsing=====
The GPS Hardware module transmits an NMEA string over UART to the SJTwo Board. We read each character one by one and add it to the Line Buffer module.
Inside its computation loop, the Line Buffer module checks if a newline character has been received.
When a newline character has been received the entire string is extracted from the line buffer module and parsed according to its identifier ($GPRMC, $GPGGA) received and parsed into individual tokens.
For our purposes the $GPRMC NMEA string was the most appropriate and it helped us extract the Current Latitude Longitude as well as the Valid/Invalid tag for the Canster Truck.

=====GPS LED Indication for debugging=====

A simple module that checks for the GPRMC GPS Message and extracts the A or V valid (Tag). If $GPRMC NMEA string is valid, LED is set, else LED is reset. This gives us onsite debugging capabilities to know if GPS has locked onto a satellite signal.

=====GEO Logic Module Computation=====
The GEO Logic Module computes the Bearing Angle, Haversine Distance as well as the Waypoints algorithm.

'''Bearing Angle:'''

<code>
θ = atan2( sin Δλ ⋅ cos φ2 , cos φ1 ⋅ sin φ2 − sin φ1 ⋅ cos φ2 ⋅ cos Δλ )
</code>

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

Since atan2 returns values in the range -π ... +π (that is, -180° ... +180°), to normalize the result to a compass bearing (in the range 0° ... 360°, with −ve values transformed into the range 180° ... 360°), convert to degrees and then use (θ+360) % 360, where % is (floating point) modulo.
For final bearing, simply take the initial bearing from the endpoint to the start point and reverse it (using θ = (θ+180) % 360).

The above article reference gives us the required bearing angle that our car must align itself to, to reach a particular destination coordinate from its current coordinate.
The Steering of the vehicle depends on the above-computed angle values.

'''Haversine Distance Formula:'''

This uses the ‘haversine’ formula to calculate the great-circle distance between two points – that is, the shortest distance over the earth’s surface – giving an ‘as-the-crow-flies’ distance between the points (ignoring any hills they fly over, of course!).

<code>
a = sin²(Δφ/2) + cos φ1 ⋅ cos φ2 ⋅ sin²(Δλ/2)

c = 2 ⋅ atan2( √a, √(1−a) )

d = R ⋅ c
</code>

where φ is latitude, λ is longitude, R is earth’s radius (mean radius = 6,371km);
note that angles need to be in radians to pass to trig functions!

The above formula is used to calculate the distance between the source coordinate (received via GPS) and the destination coordinate.
Later this was used to compute the distance between source coordinate and each individual checkpoint to traverse the shortest distance.

'''Waypoints Algorithm:'''

The Waypoints algorithm that was chosen was a slightly modified version of Djikstra’s Algorithm.
3 values were calculated before the final computation

* Distance between source and final destination (DISTsd)
* Distance between source and each individual checkpoint (DISTsc)
* Distance between each individual checkpoint and the final destination. (DISTcd)

If '''DISTsd''' was lesser than '''DISTcd''', this checkpoint was discarded (we continue in the loop). Since we would be moving in the opposite direction, rather than towards the final destination.

If '''DISTsd''' was greater than '''DISTcd''', then we checked the nearest checkpoint to the source.
The minimum value was set initial that was equal to '''DISTsd'''.

If '''DISTsc''' was lesser than the minimum value stored, '''DISTsc''' would become the new minimum value, and the checkpoint index and coordinates would be appropriately stored and returned from the function.

In this way we would navigate to the nearest checkpoint from the source, while also making sure NOT to travel in the opposite direction.
This logic is recomputed only when we reach the checkpoint selected and the algorithm runs again to find the next checkpoint that we need to navigate to.

=====CAN Decode Destination Coordinates=====
Destination Coordinates are received from the Bridge and Sensor Node and transmitted over the CAN Bus. The value is decoded and stored in the GEO Logic Module.
This is a very important value since our entire GEO Logic calculations are based on the Destination Coordinate.

=====CAN Encode and Send=====

The main messages that were transmitter are
#Geo Degree
#Geo Destination Reached
#Distance from Destination Debug and Checkpoint Index debug

'''Geo Degree Computation as per Waypoints Algorithm:'''

Geo Degree was computed as per the current coordinates and the most recently computed checkpoint coordinates. This bearing angle calculation w.r.t computed checkpoint would continue till we do not reach that particular checkpoint.
Once we reach the computed checkpoint, Waypoint algorithm is recomputed as per the process mentioned above and the algorithm runs again.

'''Geo Destination Reached:'''

An Area of around 4 meters was set around the destination coordinate to check if the destination had been reached.
This measurement was taken into consideration to allow for the loss in precision when transmitting data over CAN as well as any irregularities that might occur when getting values from the GPS.
Having an area of 4 meters was very accurate for all of our test runs.

'''Geo Distance from Destination Debug and Checkpoint Index Debug:'''

Getting debug information was very critical to speed up our development process. In this case we could actively see if our algorithm worked properly.
The Geo Distance from Destination was used to see if we were moving closer to our destination or veering further away from it.
The Checkpoint Index was used to see which checkpoint index we were traveling to. By knowing the placements of the Individual checkpoints we could manually as well as programmatically (via Android application) verify the working of our Canster Truck.

=== Technical Challenges ===
#DBC Challenge for GEO Coordinates -> Could not encode more than 5-6 decimal places at a time, on later investigation we found that the 10000 is an int value, however 100000 overflows the int value.
#Creating an efficient algorithm for Waypoints, O(n) complexity.
#Getting appropriate fixes for GPS when not in a completely open space.
#GPS used to fluctuate or stop giving values when Battery voltage went below a particular threshold. Always supply 3.3V constantly at a good amperage.

 

== '''Sensor [Bridge and Sensor Controller]''' ==
'''[https://gitlab.com/coder137/can-ster_truck/-/tree/sensor_bleeding_edge_dev GitLab]'''
==='''Ultrasonic Sensor'''===
====Hardware Design====
This sensor uses an ultrasonic beam to measure the distances. Based on the time taken between when the beam is sent and received back to the sensor, the distance is calculated in the node.
Apart from 5v and GND, this sensor has 2 pins ECHO and TRIG which are interfaced with the SJ-Two board via GPIO.

[[File:CMPE243_S20_T2_CansterTruck_ultrasonic_sensor.jpg|thumb|center|300px| Ultrasonic Sensor Diagram]]

====Software Design====
* Init the GPIO pin connected to TRIG of the sensor as output and for ECHO as an input port.
* Attach the interrupt on the ECHO input port.
* Store the system_clock_count before setting the trigger pulse and then set the pulse. Also keep monitoring the input port.
* Take the system_clock_count at the instant of receiving the interrupt.
Distance = (system_clock_count_at_trig - system_clock_count_after_at_echo) / 57.14

==='''Lidar Sensor'''===
====Hardware Design====
The RPLidar sensor can be powered from a 5v source and uses UART communication to receive commands and transmit data. It has seven pins to interface with. Two sets of the pins (four total) are for power and ground. The remaining three are for UART receive and transmit, and for making the lidar’s motor spin.

[[File:CMPE243_S20_T2_Canster_Truck_RPLidar_A1.JPG|thumb|center|300px| RPLidar A1]]

====Software Design====
In terms of the lidar, the SJ2 initializes GPIO, UART, and memory for storing the measurement values. After initialization, the command to begin scanning is sent. Here, we wait for the lidar to send a response packet, letting the host (SJ2 board) know it received the command. The response packet the lidar sends will be 7 bytes. If the correct 7 bytes are not received, the command will be sent again.

[[File:CMPE243_S20_T2_Canster Truck_Lidar_flow.jpeg|thumb|center|200px| Lidar Flow]]

Following the response packet, the lidar begins sending 5-byte measurement data. Each sample contains a distance measurement (in millimeters) and the angle (with respect to the lidar) in which it was taken. The data packet structure is shown in the following figure. In addition to containing the distance and angle, the packet includes a quality value, to indicate the reliability of the measurement, and three check bits (S, ~S, and C). As the data is received via UART, we wait until we have 5 bytes before continuing to process. Before processing the 5 bytes after receiving them, the check bits are confirmed to be correct. If they are incorrect, it will not be processed and we will wait for another sample to be received.

[[File:CMPE243_S20_T2_Canster Truck_DataPacketStructure.JPG|thumb|center|200px| Data Packet Structure]]

In the case the sample is correct, each measurement value that is in a direction of interest will be placed in an array designated to one of four directions (left, right, front, rear). Each of these directions have their own sector in the lidar’s 360-degree view.
*Right sector: 11° - 30°
*Rear sector: 170° - 190°
*Left sector: 330° - 349°
*Front sector: 350° - 370° (or 10°)

The arrays mentioned will hold roughly 20 measurements, which are every degree in the sector. In the event, objects are too far to measure, the lidar will report 0 mm. distance. Since there is no measurable obstacle, a “large” distance value of 3000 mm. is placed in the array. The smallest distance value will be taken from each array and reported to the driver node for obstacle avoidance.

=== Technical Challenges ===
====Ultrasonic Sensor====
*'''Power issue''' The pulses were getting triggered incorrectly and it took a while to figure out that it was due to insufficient power.

====LIDAR====
*'''Datasheet not 100% clear:''' The correct datasheet for the was a bit difficult to obtain, and the manufacturer needed to be contacted. The first document found online was high level and general information about the sensor, but the manufacturer did provide another document that contained the information of the commands and responses to and from the lidar, and their packet structure. The documents did not clearly state the angles with respect to the lidar are fixed, which left me wondering if the lidar will think the direction it is facing when powered on will become the new “zeroth” angle.

*'''UART Buffer Overflow:''' When first interfacing with the sensor, the incoming bytes of the lidar were printed on to the terminal to make sure there was a response and to make sense of the information. Since the command we sent results in 5 bytes of data per measurement samples from the lidar and the lidar measured 2000 times per second, there are will be roughly 10k Bytes per second of data incoming that need to be handled continuously. With an improperly sized UART buffer and print statements it is guaranteed to occur, making the lidar data look like random values.

*'''Proper Parsing of Measurement Data:''' After sending a command to the lidar, the sensor will send a response packet, followed by the measurement data. The initial response from the lidar is a 7-byte packet, followed by continuous 5-byte measurement samples. I needed to make sure however I handled the response would be independent of how the measurement is handled, so as not to create a potential unwanted offset when receiving measurements.

*'''Object Detection with Received Data:''' Once proper communication was set up with the lidar and measurement data was getting decoded, there needed to be a way to measure when obstacles were present. If ~360 measurements are handled entirely independently from one another, it could become a complex and confusing code. To achieve a simple approach, four sectors about 20 degrees in size were used to represent the front, left, right, and rear directions.

*'''Bugs in Code:''' When first implementing the code, there were a few bugs from typos, incorrect numbers, and some faulty logic that were found with the use of unit testing. Unit testing helped find these issues and verified the logic was correct, and I would say gave me 90% confidence in my lidar handling.

 

== '''Bluetooth Module [Bridge and Sensor Controller]'''==

Bridge functionality of the Bridge and Sensor Controller is to establish wireless communication between the SJ-2 Board and the android mobile device using the HC-05 Bluetooth module. The Bridge controller will be receiving start command with destination GEO coordinates and stop command. The Bridge controller will be transmitting the required sensor data and debug information to be displayed on the android application.

[[File:CMPE243_S20_T2_BRIDGE.png|thumb|center|500px| Bridge Diagram]]

==== Software Design ====

'''Low-Level Layer'''

In this layer, similar to the GPS the UART GPIO was initialized (RX, TX), FreeRTOS Queue was initialized for UART Interrupts and the line buffer module was initialized to parse strings.

Two basic functions <code>bt__read</code> and <code>bt__write</code> were implemented.
As the name suggested, <code>bt__write</code> took a string as its input parameter and transmitted that data to the Android application. <code>bt__read</code> stored the incoming characters into the line buffer, parsed the line received into its identifier and tokens, and invoked a callback function.

Since this was a low-level layer the User would not be directly invoking this library. Instead a '''Bluetooth Wrapper''' module was created which would be invoked and used by the user.

'''Application Layer'''

The Bluetooth Wrapper module had the appropriate <code>read_once</code> and <code>write_once</code> functions.

The <code>read_once</code> function internally just called the <code>bt__read</code> function. All of the decodings was done inside the Callback Function.
To get the Destination coordinate the string received from the Android Application was in the form of
<code>$loc,<destination_latitude>,<destination_longitude>.</code>
Upon receiving this data we parsed the destination_latitude and destination_longitude, which could later be accessed using getters.
We also set a start flag to notify the Driver Node that destination has been received and we can start steering towards our checkpoints.

Another command implemented was the stop command.
<code>$stop</code>
This was used to send a stop flag to the Driver node.

The <code>write_once</code> function used the getter methods from each CAN Decode message and update its internal state variables. A CSV String was created using the <code>$canster</code> identifier and various debugging points were appended to this message using a comma.
On the Android application side this CSV string was tokenized and displayed onto the Application Debug screen appropriately.

==== Technical Challenges ====

'''Bluetooth peripheral not turning on'''
* We initially connected the Bluetooth module directly to the SJ-Two board with (Vcc = 3.3v). But it was not giving only 2.7v and hence the device did not turn on.
* We had to connect it to external power source to make it function without hassles.

 

== '''Driver [Driver and LCD Controller]''' ==
'''[https://gitlab.com/coder137/can-ster_truck/-/tree/driver_bleeding_edge_dev GitLab]'''

=== Software Design ===

[[File:CMPE243_S20_T2_Canster Truck_Driver_Flowchart.png|thumb|center|750px|Driver Flowchart]]

The above block diagram explains the process flow of obstacle detection for the car. The LIDAR detects
the obstacle and depending on the distance of obstacle the car takes a slight right and slight left or a
hard right and hard left. The state of the car also depends on the value of the LIDAR and ultrasonic sensor.
The loose ends of the LIDAR for the reverse condition are checked by the ultrasonic sensors. The
The ultrasonic sensor works on the principle of trigger and echo and can detect the obstacles very close by.
The range of the Ultrasonic sensor is lower than the LIDAR. Finally, if no obstacle is detected the car goes
straight until the destination is reached. The speed of the car is also various when an obstacle is detected to
avoid the crash and the car’s smooth transition from one state to another. The key to the android
application controls the start and stop the process of the car. If the key is not pressed, then the stays in the

neutral state. The speed of the car is controlled by the changing duty cycle of the input voltage. There
are seven-speed levels in which the motor can run on. These speed levels are Forward Slow, Medium,
Fast, Reverse Slow, Medium, Fast, and Neutral. The Neutral is the stop condition with a 0% duty cycle.

=== Technical Challenges ===

Technical Challenges faced during obstacle detection:

*Due to dimensions of the car and for the perfect obstacle avoidance the values of 100cm and 150cm had to be selected for the turning radius. Hence, it is very important to calibrate these values appropriately, as these values will be unique for different car designs.
*For a situation, where even if the lidar doesn’t detect any obstacle at the middle, the car must take a slight right or a slight left as per our design. This is the case where the obstacle can be a moving one and that is why the lidar middle couldn’t detect it.

 

== '''LCD [Driver and LCD Controller]''' ==
=== Hardware Design ===
[[File:CMPE243_S20_T2_Canster_Truck_LCD_Diagram.png|thumb|600px|center| LCD Design]]
{|style="text-align: center; width: 400px; height: 200px; margin: auto;"
|
[[File:CMPE243_S20_T2_Canster_Truck_GLCD.jpg|thumb|200px|center| GLCD Hardware]]
||
[[File:CMPE243_S20_T2_Canster_Truck_GLCD2.jpg|thumb|600px|center| GLCD Software Simulation]]
|
|}

=== Software Design ===
The GLCD used was created by 4DSystems, using their IDE a UI was created. Each UI component could be controlled by sending UART data targeted at the widget address.
The best part about this GLCD was that we had a lot of interactive widgets to display debugging information in real-time.
The GLCD code was divided into 3 parts:

=====Low-Level Initialization=====
Initialize the low-level hardware interfaces to send and receive data from the GLCD.
Similar to the GPS and Bluetooth, The UART GPIO was initialized (RX, TX), FreeRTOS Queue was initialized for UART Interrupt and line buffer was used to get a stream of data for parsing.

Low-level '''read''' and '''write''' commands were used as per the working of the GLCD Module.
When Reading data pertaining to a widget on the GLCD we would need to send a particular response packet.

<pre>
void lcd__read(lcd_object_e object_id, uint8_t object_index, uint8_t *response, uint16_t *response_data) {

uint8_t checksum = READ_OBJ ^ object_id ^ object_index;
uint8_t buffer[] = {READ_OBJ, object_id, object_index, checksum};

lcd__write_data(buffer, sizeof(buffer) / sizeof(uint8_t));
lcd__read_response_id(response);
lcd__read_response_data(response_data);
}
</pre>

The response_data returned contains the Widget ID as well as the current value stored on that widget.

When Writing data pertaining to a widget on a GLCD the process is similar to the above mentioned code.
<pre>
void lcd__write(lcd_object_e object_id, uint8_t object_index, uint8_t msb, uint8_t lsb, uint8_t *response) {
uint8_t checksum = WRITE_OBJ ^ object_id ^ object_index ^ msb ^ lsb;
uint8_t buffer[] = {WRITE_OBJ, object_id, object_index, msb, lsb, checksum};

lcd__write_data(buffer, sizeof(buffer) / sizeof(uint8_t));
lcd__read_response_id(response);
}
</pre>

However in this case we receive only an ACK or NACK from the system. ACK would mean that the write to GLCD widget was successful and the widget now stored appropriate values. NACK would mean that a particular error has occurred. The errors could be regarding baud rate, incorrect bit format, incorrect index values, etc.

=====GLCD Wrapper for Widgets=====
The above low-level code had generic read and write functions. However for our UI we were only using 3 Widgets. All of which had '''different Indexes''' and '''Widget IDs'''.
Therefore a very simple library was created to easily interface with those widgets
<pre>
bool lcd_wrapper__read_led(uint8_t index);
uint16_t lcd_wrapper__read_meter(uint8_t index);
uint16_t lcd_wrapper__read_leddigit(uint8_t index);

bool lcd_wrapper__write_led(uint8_t index, bool value);
bool lcd_wrapper__write_meter(uint8_t index, uint16_t value);
bool lcd_wrapper__write_leddigit(uint8_t index, uint16_t value);
</pre>

The above code is self-explanatory read and write functions for '''LED''', '''METER''', and '''LED DIGIT'''.

=====GLCD UI=====
Now that we had our low level and Widget wrapper working properly, we wanted to create our Dynamic UI as well. The code would need to be robust enough to handle any UI that we create on the GLCD which could be reflected equivalently in our C Code.

<pre>
static void lcd_ui__update_ui(void) {

lcd_wrapper__write_led(LCD_LED_DRIVER_MIA_INDEX, driver_mia_led);
lcd_wrapper__write_led(LCD_LED_SENSOR_MIA_INDEX, sensor_mia_led);
lcd_wrapper__write_led(LCD_LED_GEO_MIA_INDEX, geo_mia_led);
lcd_wrapper__write_led(LCD_LED_MOTOR_MIA_INDEX, motor_mia_led);

// kph is always in the range of 0 - 10
lcd_wrapper__write_meter(LCD_METER_KPH_INDEX, kph_meter % 11);

// These will be in the Range of 0-99
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_RPM_INDEX, rpm_leddigit % 100);
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_CURRENTDEGREE_INDEX, cdegree_leddigit % 100);
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_REQUIREDDEGREE_INDEX, rdegree_leddigit % 100);
}
</pre>

As we can see the `lcd_ui__update_ui` function was called periodically inside the 1Hz function. It updated the screen in real time based on the static values that were stored AND updated inside the LCD UI module.
The Constant INDEX values stored were directly mapped onto the Index values were received from the 4DWorkshop UI Software.

=== Technical Challenges ===

*The GLCD needs to be supplied appropriate voltage (5V) at 1A for it to work properly. The LCD does not turn on without an appropriate power supply
*The GLCD UART interface has an additional RES signal. This RES signal resets the GLCD when pulled low. When connecting the UART display it is recommended to always reset the GLCD display for proper working
*The GLCD has a latency of up to 30ms when querying and receiving data. In our case, the real-time system has hard caps on time (i.e up to 1second of delay is possible on the 1Hz function)
*This was rectified by putting the read functions (if any) inside the low priority 1Hz periodic_callback function.
*Write operations do not suffer from such a latency issue since they only send one byte (ACK or NACK) signal back.
*Fortunately most of our logic involved just a write (setting a value on the GLCD) rather than reading or querying the widget.

 

== '''Android Application''' ==
[https://gitlab.com/akhilcherukuri/can-ster_truck_application Gitlab]
=== Software Design ===

<div><ul>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android4.jpg|thumb|none|220px|Info Activity (Top)]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android7.jpg|thumb|none|220px|Info Activity (Middle)]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android5.jpg|thumb|none|220px|Info Activity (Bottom)]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android6.jpg |thumb|none|220px|Debug Activity Screen]]</li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster_Truck_Android_GIF1.gif|thumb|center|220px|App Animations]]</li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster_Truck_Android_GIF2.gif|thumb|center|220px|Live Location]]</li>
</ul></div>
The application consists of a total of 5 Activities:

=====Main Activity=====
**This is the app launch display screen
**It will check for all the required permission onStart().
**Has search button for connecting from a paired device list view
**Once device is clicked, an intent will start the Map Activity
=====Map Activity=====
* For this requirement we are using the Google Maps Fragment, for the map fragment to function we must request an API key from Google and set the key in the manifest of the application.
* Destination marker(Red Marker) is set using <code>setOnMapClickListener</code> to which the car will navigate to, the destination can be changed by clicking elsewhere on the Map Fragment. The marker can be removed using <code>setOnMarkerClickListener</code>.
* When the start button is pressed, the start command identifier along with destination latitude and longitude is sent to the car via the write thread. A background thread is started along with it to indicate the current car's position(Green Marker) along with a plotline between the current position and destination.
* When the stop button is pressed, the stop command identifier is sent to the car, to stop and turn off the car.
=====Info Activity=====
* Messages from Geological, Driver, Motor coming from CAN bus are decoded by the Sensor and Bridge controller and sent to the Android application as a string.
* The received string is parsed and categorizes the data to store it in the required textView to be displayed.
* Bluetooth status, Lidar Values, Ultrasonic Sensor Values, Motor Speed, Motor RPM, Motor PWM, Cars' current location, Compass Heading, Distance till Destination, Checkpoint Index is displayed. This was useful for debugging purposes and allowed us to avoid scanning the mounted LCD or CAN Busmaster on PC during drives.
=====Debug Activity=====
*The main function of this activity is to check all RAW RX and RAW TX messages and create a log of all the data received and sent.
=====Bluetooth Connection Service Activity=====
*This is the background activity that handles all the threads required for transmission and receiving data using Bluetooth connections. It has 3 running threads which is called inside other activities using a handler:
* Accept Thread - Listens to BluetoothServerSocket using listenUsingRfcommWithServiceRecord. In order for the RF communication socket to connect to the HC-05, we used the following <code>UUID: 00001101-0000-1000-8000-00805F9B34FB</code>. This is a generic SSP Bluetooth UUID that enables the socket to directly connected to HC-05 and maintain the connection.
* Connect Thread - Creates a Bluetooth socket using createRfcommSocketToServiceRecord
* Connected Thread - Creates socket.getInputStream(); and socket.getOutputStream(); when bytes are available in input stream it will read them into a buffer.
**All messages for activities are done by <code> Handler mHandler.obtainMessage(); mHandler.sendMessage(); </code>

'''Receieved string:'''
* A String is sent to the Bluetooth app from HC-05 and when it receives a string with identifier "$canster", the message is prased accordingly by using the string delimiter ',' and is ended by the newline character '\n' which will remove the data from StringBuffer.
* <code>Example: $canster,37.339334,-121.881123,37.338713,-121.880685,10.123,20.133,30.123,10.5,88.1,99.2,-2,1,44,7,11,22,33,-3,23\n</code>

'''Manifest:'''
<pre>
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.INTERNET" />
</pre>

'''Dependencies:'''
<pre>
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'com.google.android.gms:play-services-maps:17.0.0'
compile 'com.google.maps.android:android-maps-utils:0.4+'
implementation 'androidx.cardview:cardview:1.0.0'
implementation 'com.google.android.gms:play-services-location:17.0.0'
implementation 'androidx.appcompat:appcompat:1.1.0'
implementation 'androidx.constraintlayout:constraintlayout:1.1.3'
implementation 'com.android.support:design:28.0.0'
implementation 'androidx.navigation:navigation-fragment:2.2.1'
implementation 'androidx.navigation:navigation-ui:2.2.1'
implementation 'androidx.lifecycle:lifecycle-extensions:2.2.0'
</pre>

[[File:CMPE243_S20_T2_BLUETOOTHFLOWCHART.png|thumb|center|650px| Android Application Flowchart]]

=== Technical Challenges ===
*'''Bluetooth Discovery:''' While creating the android application, we were not able to see any Bluetooth devices in the paired device list. The problem was that for the Android versions above Lillipop we would also need location access. We have solved it by writing a function to check whether to check for permissions or not.
<pre>
private void checkBluetoothPermissions() {
Log.d(TAG, "checkBTPermissions: Checking permissions");
int permission_check = this.checkSelfPermission("Manifest.permission.ACCESS_FINE_LOCATION");
permission_check += this.checkSelfPermission("Manifest.permission.ACCESS_COARSE_LOCATION");
if (permission_check != 0) {
this.requestPermissions(new String[]{Manifest.permission.ACCESS_FINE_LOCATION, Manifest.permission.ACCESS_COARSE_LOCATION}, 1001); //Any number
}
else{
Log.d(TAG, "checkBTPermissions: No need to check permissions. SDK version < LOLLIPOP.");
}
}
</pre>
*'''Catching NULL in a StringTokenizer: ''' When sending data using Bluetooth sometimes thee app crashes. Using debug Run log in Android Studio IDE, we have found out that this is because we get <code> NullPointerException, java.util.StringTokenizer </code> error. This is mainly due to passing a null value to the StringTokenizer constructor. This problem can be avoided by after reading a line from the Bluetooth StringBuffer, we check whether it is null, before passing it to the StringTokenizer, but later on, we have preferred to use <code>split();</code> to prase the received string as StringTokenizer is now a legacy class that is retained for compatibility reasons and its use is discouraged in new code.

*'''XML Layouts: ''' Generating layouts is difficult for new android code developers, the design layouts made should be compatible for a wide range of mobile devices but using the new android libraries we have found that, the older phones then tend to have difficulty in showing the layouts correctly. We have solved this problem by learning the design commercial XML design layouts by following tutorials on Udemy and Youtube.

*'''Auto Connect''': During the first stages we have implemented Bluetooth connection via searching for all devices and clicking on the device from Listpair to connect. This has a lot of time to process all the discovered devices near range. To solve this we have hardcoded the HC-05 device address <code>00:14:03:06:02:83</code> to <code>mBluetoothAdapter.getRemoteDevice("device address")</code>.

 

== '''Management''' ==
===Git Management===

Git Management amongst 6 team members was definitely a very challenging task. Depending on our initial design we could’ve had a lot of merge conflicts. However those risks were mitigated by spending a LOT of time in the initial stages to decide our pipeline and structure.

<li>There are certain components in our system that were COMMON. For example the CAN initialization, communication and decodes were all similar for the most part between all the 4 Controllers. The utility modules used were also similar in nature</li>
<li>Thus we made a common branch that contained the templates for CAN Nodes (not Controllers), Hardware code and Utility functions.
<ol>
<li>Later this common branch was forked into an individual Controller specific branch (SENSOR, GEO, MOTOR or DRIVER).</li>
<li>Only the Logic folder contained Controller specific code, specific to that controller.</li>
</ol>
<li>This gave us a lot of flexibility since all the team members had similar APIs to work with on all 4 branches. This promoted easy understanding and learning.
<ol>
<li>Many team members frequently worked on 2 or more controllers at a time where can messages were concerned. Having a APIs also meant that just the can_handler needed to be updated regularly followed by the equivalent logic code. </li>
<li>Inside the logic folder, getters to the can node modules were frequently used.</li></ol>
<pre>
├───can_module
│ ├───can_bus_initializer
│ ├───can_constants
│ ├───can_driver_node
│ ├───can_geo_node
│ ├───can_handler
│ ├───can_motor_node
│ ├───can_sensor_node
│ └───test
├───hardware
│ ├───bt
│ ├───compass
│ ├───gps
│ ├───lcd
│ ├───lidar
│ ├───motor
│ ├───test
│ └───ultrasonic
├───logic
│ ├───driver_obstacle
│ ├───driver_state
│ ├───geo_logic
│ └───test
└───utility
├───line_buffer
└───test
</pre>

'''Challenges'''
<li>It was initially a bit of a learning curve to understand the flow of the repository</li>
<li>When using a git management system with different versions in each branch it became very tough when the number of branches suddenly exploded in size. A lot of relevant code was stuck in a lot of different branches.
<ol>
<li>This happened mainly due to assignment submissions and unclosed MRs that eventually became stale.</li>
<li>Our strategy was to abandon these MRs and keep forking from these branches without merging it back into its final controller branch.</li>
<li>The latest branches that were kept were aptly named `<controller>_bleeding_edge_dev` branches since they were never merged back from where they were forked.</li>
</ol>
<li>Since a lot of our code also depended on the DBC autogenerated code, we could not suddenly change the DBC Message names once they were established since it caused a change in the Struct name that was generated and used.
<ol>
<li>Our solution to this was to keep everything backward compatible. We added new function names without deleting old DBC messages.</li>
<li>In certain places where we wanted to modify a function name it was done one by one so that a lot of the code is not broken at one time.</li>
</ol>
<li>Common Branches eventually became stale as our progress continued on the bleeding edge branches
<ol>
<li>For example certain GPS features needed to be added which were done on the GEO_bleeding_edge_dev branch but never pushed or cherry-picked back into the COMMON branch.</li>
<li>This was a similar issue to our 2nd point but manageable since the goal of the COMMON branch was to provide a template for further work and nothing more.</li>
<li>At the end of the day each controller is its own Individual Project and while the messages between them are same. The Hardware code does not need to be same.</li>
<li>This also prompted team-members to ask if we could delete unused hardware or logic file code (which wasn’t being used and was imported from the template). This was also fine and can be done during cleanup stage. However we eventually got used to the Modular system of our project so much so that we did not worry about the additional modules that were present in each branched controller project.</li>
</ol>

 

== '''Conclusion''' ==
CMPE243 gives one of the best experiences one could ever get in their academic life. The course is designed to give an insight into how the industry functions and enhances both technical and management skills. Apart from learning how to work and implement application of CAN protocol, one can get a hands-on experience with version control, unit-testing and software design. Overall it was a very great and memorable journey.

=== Project Video ===

=== Project Source Code ===
* [https://gitlab.com/coder137/can-ster_truck GitLab Link]

=== Advise for Future Students ===
'''GENERAL:'''
* Form your team and start the project as early as you can.
* Clearly discuss what role each individual should do and ensure that progress is regularly tracked so that the team doesn't fall back on any schedule.
* Make sure your early structure of the project is decided. Before you start to write the code make sure that all the team and code guidelines are discussed. In our case we spent most of our first week deciding how we wanted to structure and design our code. This paid off in the long run since we had robust code inside one repository that could be extended efficiently.
* Make sure each module is individually testable i.e through periodic callbacks as well as unit-tests. While unit-tests can help for a lot of situations and provide a robust way to map the working of the module, it cannot simulate certain real-life scenarios. For example, Lidar buffer was constantly getting full due to the large number of incoming bytes. This caused us to have certain incorrect reading appear after a few minutes of the lidar running. Our solution was to minimize the <code>printf</code> statements inside the module that were used for debugging.
* Since lot of code and hardware integration is involved with this project, make sure testing is thoroughly and periodically done and make note of all the issues found.
'''HARDWARE:'''
* Decide on how you would power up the peripherals. We had issues with Bluetooth (not connecting), GPS (lock not happening) and LIDAR (giving incorrect values). After lot of cycles of hardware and software debugging, we found that the issue was with power. Choose wisely as to which peripherals must be connected to which power source.
* Isolate the power hungry devices to other parallel connections so that the voltage drop is not high. In our case the Graphical LCD and LIDAR were both very power hungry peripherals. The LCD used to start glitching incase there was a large voltage drop and the LIDAR used to give incorrect values or not update correctly. We solved this issue by giving the lidar a dedicated power supply.
* PCB design involves lot of hardware components. Coordinating with multiple team members and verifying each hardware connection takes quite some time. So start well ahead.
* Make sure to expose some extra GPIO and GND pins for future use.
'''MOTOR:'''
* You can use the LiPo battery to power the RPM and servo motor instead of using a separate power source. Use Vout from the ESC to get 6V.
* Start the PID control calibration early on as you will need to do extensive testing to get it working.

=== Acknowledgement ===
<HR>
Firstly we would like to express our gratitude to Professor Preetpal Kang for his guidance throughout the semester and providing us with this opportunity. We would also like to thank the ISA members Vignesh Kumar Venkateshwar and Aakash Vrajlal Chitroda for being available whenever in need and guiding us to complete the project.

== '''References''' ==
* CAN Reference [https://www.kvaser.com/about-can/can-dictionary/]
* FreeRTOS Reference [http://socialledge.com/sjsu/index.php/FreeRTOS_Tutorial]
* Git tutorial [http://socialledge.com/sjsu/index.php/Basic_Git_Tutorial]
* Unit-test reference [https://gitlab.com/sibros_public/public/-/wikis/c/unit_tests#lab-1]
* Getting started with SJ-Two [https://sjsu-dev2.readthedocs.io/en/latest/getting_started/getting_started/]

===Motor Controller===
* Traxxas User Manual: [https://images-na.ssl-images-amazon.com/images/I/D1NTpa7RNES.pdf]
* Traxxas Specification Sheet: [https://images-na.ssl-images-amazon.com/images/I/81WphBAuwIL.pdf]

===Geological Controller===
* Movable Scripts (Calculate distance, bearing and more between Latitude/Longitude points): [https://www.movable-type.co.uk/scripts/latlong.html]
* CMPS11 (I2C Configuration): [https://www.robot-electronics.co.uk/htm/cmps11i2c.htm]

===Bridge and Sensor Controller===
* [https://www.slamtec.com/en/Lidar/A1 LIDAR]
* [https://components101.com/ultrasonic-sensor-working-pinout-datasheet Ultrasonic sensor ]
===Driver and LCD Controller===
* LCD Software: [https://4dsystems.com.au/ulcd-32ptu 4Dsystems]
===Android===
* Youtube Channel: [https://www.youtube.com/channel/UCoNZZLhPuuRteu02rh7bzsw Coding with Mitch]
* Android Developers: [https://developer.android.com/guide/topics/connectivity/bluetooth Website][https://github.com/googlearchive/android-BluetoothChat Github]
* Udemy Course: [https://www.udemy.com/course/the-complete-android-oreo-developer-course/ Complete Android Oreo Developer Course]
===PCB Design===
* Design Tool: [https://easyeda.com/ EasyEDA]

S20: Canster Truck

2020-05-22T05:49:45Z

Proj user22: /* GEO Logic Module Computation */

[[File:CMPE243_S20_T2_Canster_Truck_Logo.png|thumb|455px|caption|right|CAN-STER TRUCK LOGO]]

== '''Abstract''' ==
'''The Canster Truck Project is an autonomous RC car with CAN Bus interfaced controllers. The development of the RC car's subsystem modules (Interfacing of Ultrasonic Sensor, LIDAR, Bluetooth, GPS, Compass and CAN modules) was divided among six team members. The aim of the project is to develop an autonomous RC Car which can navigate from one source location to the selected destination on the app by avoiding obstacles in its path using sensors. Waypoints algorithm is used as the path finding technique.'''

 

== '''Introduction and Objectives''' ==

'''The project was divided into 7 modules:'''

* '''Bridge and Sensor Controller'''
* '''Motor Controller'''
* '''Geological Controller'''
* '''Driver and LCD Controller'''
* '''Hardware Integration'''
* '''Android Application'''
* '''Testing & Code Review'''

'''RC Car Objectives'''
'''1. Driver and LCD Controller''' - Handles algorithms for obstacle avoidance, route maneuvering, and waypoints
'''2. Geological Controller''' - Recieves coordinates from GPS and Heading from Compass for navigation
'''3. Motor Controller''' - Controls movements of the RC Car
'''4. Bridge and Sensor Controller''' - Detects surrounding objects and interfaces android application to controller via bluetooth
'''Team Objectives'''

[[File:CMPE243_S20_T2_High_Level_System_Diagram.png|thumb|center|800px| High Level System Diagram]]

 

== '''Team Members and Responsibilities''' ==

'''Gitlab Project Link''' - [https://gitlab.com/coder137/can-ster_truck '''Canster Truck''']
 

*'''Niket Naidu''' [https://www.linkedin.com/in/niket-naidu-30090a134/ LinkedIn] [https://gitlab.com/coder137 Gitlab]
** '''Geological Controller''' : Waypoint Algorithm, Haversine and Bearing Angle logic
** '''Driver and LCD Controller''' : GLCD
** '''Bridge and Sensor Controller''' : Bluetooth
** '''Testing & Code Review'''

*'''Ganesh Ram Pamadi''' [https://www.linkedin.com/in/ganeshram93/ LinkedIn] [https://gitlab.com/ganeshram2493 Gitlab]
** '''Hardware Integration'''
** '''Testing & Code Review'''
** '''Driver Controller'''
** '''Motor Controller'''

*'''Nikhil Pabbisetty''' [https://www.linkedin.com/in/nikhilpabbisetty/ LinkedIn] [https://gitlab.com/nikhilpeoria Gitlab]
** '''Bridge and Sensor Controller'''
** '''Motor Controller'''

*'''Akhil Cherukuri''' [https://www.linkedin.com/in/akhilcherukuri/ LinkedIn] [https://gitlab.com/akhilcherukuri Gitlab] [https://github.com/akhilcherukuri Github]
** '''Android Application'''
** '''Bridge and Sensor Controller'''

*'''Ashish Anant Ladage''' [https://www.linkedin.com/in/ashish-anant-ladage-7bb3a214b/ LinkedIn] [https://gitlab.com/ashishladage1 Gitlab]
** '''Driver and LCD Controller'''
** '''Hardware Integration'''
** '''Motor Controller'''

*'''Jesus De Haro De Reza''' [https://www.linkedin.com/in/jesus-de-haro-66342424/ LinkedIn] [https://gitlab.com/deharo27 Gitlab]
** '''Bridge and Sensor Controller'''
** '''Motor Controller'''

 

== '''Administrative Responsibilities''' ==
* '''Team Lead''' - [https://www.linkedin.com/in/niket-naidu-30090a134/ '''Niket Naidu''']
* '''Git Repository Manager''' - [https://www.linkedin.com/in/niket-naidu-30090a134/ '''Niket Naidu''']
* '''Bill Of Materials Manager''' - [https://www.linkedin.com/in/akhilcherukuri '''Akhil Cherukuri''']
* '''Wiki Report Manager''' - [https://www.linkedin.com/in/akhilcherukuri '''Akhil Cherukuri''']

 

== '''Schedule''' ==

{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-

! scope="row"| '''1'''
| style="text-align:center;" |'''02/11/2020'''
| style="text-align:center;" |'''02/17/2020'''
|
*'''Form teams and decide group name'''
*'''Review past projects'''
*'''Slack: Create project group and invite Preet'''
*'''GitLab: Create project groups repository'''
*'''Analysis of component required'''

|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''2'''
| style="text-align:center;" |'''02/18/2020'''
| style="text-align:center;" |'''02/24/2020'''
|
*'''Study CAN Communication'''
*'''Create Bill of Materials'''
*'''Order RC Car'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''3'''
| style="text-align:center;" |'''02/25/2020'''
| style="text-align:center;" |'''03/02/2020'''
|
*'''Setup team finance management using Splitwise application'''
*'''Complete Bill of Materials'''
*'''Order all other required components'''
*'''Wikipedia: Setup project report template'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''4'''
| style="text-align:center;" |'''03/03/2020'''
| style="text-align:center;" |'''03/09/2020'''
|
*'''Read the respective datasheets and manuals for each component'''
*'''Test each component for working conditions'''
|
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''5'''
| style="text-align:center;" |'''03/10/2020'''
| style="text-align:center;" |'''03/16/2020'''
|
*'''Assign team responsibilities and roles'''
*'''Setup team project management environment (ClickUp)'''
*'''Define CAN DBC'''
*'''Research GPS antennas and order'''
*'''Android: Environmental setup of Android Studio and enable version control'''
*'''Hardware : Decide PCB editing software (easyEDA)'''
*'''Hardware : Draft schematic for required PCB design'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''6'''
| style="text-align:center;" |'''03/17/2020'''
| style="text-align:center;" |'''03/23/2020'''
|
*'''Hardware : Create model of PCB''' 
*'''Android: Add a Button for changing bluetooth connection status in the application''' 
*'''Geological: Interface Compass module with SJ-2 board using I2C interface''' 
*'''Geological: Interface GPS module with SJ-2 board using the UART interface''' 
*'''Geological: Parse raw data to get meaningful values for GPS and Compass''' 
*'''Sensor: Interface and check the functionality of ultrasonic sensors to the SJ-2 board''' 
*'''Motor: Interface of Servo & DC motor to the SJ-2 board and check for basic functionality''' 
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''7'''
| style="text-align:center;" |'''03/24/2020'''
| style="text-align:center;" |'''03/30/2020'''
|
*'''Hardware : Finalize components placement on PCB.''' 
*'''Motor: Add PWM functionality and test the code on DC and servo motors''' 
*'''Sensor: Interface and check and study the output readings of Lidar sensor with SJ-2 board over UART''' 
*'''LCD Display: Explore UI designing of LCD''' 
*'''Hardware: Finalize on optimal ultrasonic sensor placements''' 
*'''Android: Initiate Bluetooth communication and show staus via text view''' 
*'''Wikipedia: Establish final wiki schedule'''
*'''Complete CAN communication format for each controller and link DBC file to the Wiki'''
*'''Complete high-level system block diagram'''
*'''Complete unit-level block diagrams'''
*'''Bridge: Interface HC-5 bluetooth module with Sj-2 board using serial communicaton'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''8'''
| style="text-align:center;" |'''03/31/2020'''
| style="text-align:center;" |'''04/06/2020'''
|
*'''Hardware: Analyze PCB model and order PCB Circuit board''' 
*'''Android: Initiate Bluetooth communication and send "Hello World".''' 
*'''Wikipedia: Start adding information/images/diagrams to the relevant sections'''
*'''Motor: Configure ESC for correct speed outcome according to frequency & PWM values''' 
*'''Motor: Finish RPM sensor hardware and software implementation and integration''' 
*'''Sensor: Read output from Lidar and setup structure for outputting for DBC''' 
*'''Geological: Implement waypoints algorithm''' 
*'''Driver: Implement obstacle avoidance algorithm''' 
*'''Bridge: Pass data such as "Hello World" from HC-05 bluetooth module to bluetooth terminal android application'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''9'''
| style="text-align:center;" |'''04/07/2020'''
| style="text-align:center;" |'''04/13/2020'''
|
*'''Hardware: Remove Unused parts from RC Car''' 
*'''Hardware: Mount PCB and 3D Parts''' 
*'''Motor: Decide different cut-off values from sensor to command right /slight right/ straight/ slight left/ left to motor.''' 
*'''Android: Embed Google Maps API for setting the car's destination.''' 
*'''LCD: Work to show RC cars live status information(battery level, current speed, long, lat, bearing, sensor data, etc)''' 
*'''Driver: Test obstacle avoidance algorithm and fine-tune sensor readings''' 
*'''Geological: Test checkpoint algorithm''' 
*'''Bridge: Establish two way communication between android application and bluetooth module''' 
*'''Update Bill of Materials for miscellaneous hardware'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''10'''
| style="text-align:center;" |'''04/14/2020'''
| style="text-align:center;" |'''04/20/2020'''
|
*'''Hardware: Integrate all hardware modules''' 
*'''LCD: Testing & Validation of the LCD UI and display vehicle status information''' 
*'''Android: Send car location to the app and checkpoints received to Geo module''' 
*'''Motor: Optimize PID control by accelerating/decelerating as instructed by Driver''' 
*'''Bridge: Configure HC-05 for auto reconnection if bluetooth communication disconnects''' 
*'''Add multiple debug messages and transmit on CAN'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''11'''
| style="text-align:center;" |'''04/21/2020'''
| style="text-align:center;" |'''04/27/2020'''
|
*'''Android: Send additional vehicle status information from RC car to the Application for display''' 
*'''Android: Finalize User Interface Design and Icon''' 
*'''Continuously test the whole system and handling of corner cases (outside).'''
*'''Finalize RC Car For Project Proto 1'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''12'''
| style="text-align:center;" |'''04/28/2020'''
| style="text-align:center;" |'''05/04/2020'''
|
*'''Gitlab: Push final code'''
*April 28th: Project Proto 1
*'''Finalize RC Car for Project Demo'''
*May 1st: Project Presentation
*'''Finalize RC Car for Project Proto 2'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''13'''
| style="text-align:center;" |'''05/05/2020'''
| style="text-align:center;" |'''05/21/2020'''
|
* '''Complete Individual Contribution Peer Grading'''
* '''Review and Complete Wiki Project Page'''
|
*'''Completed'''
*'''In Progress'''
|-
|}

 

== '''Bill Of Materials''' ==
{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Item#
! scope="col"| Part Description
! scope="col"| Part Model & Vendor
! scope="col"| Quantity
! scope="col"| Cost in USD
|-
! scope="row"| 1
| '''Microcontroller Boards'''
| SJ2 Boards (Purchased from Preet Kang)
| 4
| $200.00
|-
! scope="row"| 2
| '''CAN Transceivers'''
| [https://www.waveshare.com/sn65hvd230-can-board.htm Waveshare SN65HVD230]
| 12
| $54.48
|-
! scope="row"| 3
| '''RC Car'''
| [https://www.amazon.com/Traxxas-Slash-Course-2-4GHZ-Vehicle/dp/B01DU474B0/ref=sr_1_3?ie=UTF8&qid=1474747759&sr=8-3&keywords=Traxxas+1%2F10+slash+2wd Traxxas 2WD RTR with 2.4Ghz Radio]
| 1
| $260.00
|-
! scope="row"| 4
| '''Lithium-Ion Battery'''
| [https://www.rcsuperstore.com/traxxas-7600mah-2s-7-4v-25c-id-lipo-battery-pack/ Traxxas 7600mAh 2S 7.4V 25C iD LiPo Battery Pack]
| 1
| $75.00
|-
! scope="row"| 5
| '''Lithium-Ion Battery Charger'''
| [https://www.amazon.com/Traxxas-2970-EZ-Peak-Charger-Identification/dp/B00OAFYLJC/ref=pd_bxgy_21_img_2?ie=UTF8&psc=1&refRID=JVX791WVV9Y8T9DW92KW Traxxas 2970 EZ-Peak Plus 4-Amp NiMH/LiPo Fast Charger]
| 1
| $50.00
|-
! scope="row"| 6
| '''Compass Breakout Board'''
| [https://www.dfrobot.com/product-1275.html DFRobot CMPS11 Compass]
| 1
| $29.99
|-
! scope="row"| 7
| '''Bluetooth Breakout Board'''
| [https://www.amazon.com/HC-05-Bluetooth-Pass-through-Wireless-Communication/dp/B01G9KSAF6/ref=sr_1_4?ie=UTF8&qid=1507077325&sr=8-4&keywords=arduino+bluetooth+hc-05 DSD TECH Bluetooth HC-05]
| 1
| $8.49
|-
! scope="row"| 8
| '''LIDAR Sensor'''
| [https://www.amazon.com/RPLiDAR-A1M8-Degree-Laser-Scanner/dp/B07H7X3SFF/ref=sr_1_fkmrnull_1?crid=2FSUI76G4UA8K&keywords=rplidar+a1m8+-+360+degree+laser+scanner+development+kit&qid=1552764172&s=gateway&sprefix=RPlidar%2Caps%2C263&sr=8-1-fkmrnull SEEED STUDIO RPLIDAR A1M8]
| 1
| $109.99
|-
! scope="row"| 9
| '''RPM Sensor'''
| [https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM Traxxas 6520 RPM Sensor]
| 1
| $13.70
|-
! scope="row"| 10
| '''GPS Breakout Board'''
| [https://www.adafruit.com/product/746 Adafruit Ultimate GPS Breakout v3]
| 1
| $44.30
|-
! scope="row"| 11
| '''LCD Display'''
| [https://4dsystems.com.au/ulcd-32ptu 4Dsystems 3.2 TFT-LCD ULCD-32PTU]
| 1
| $79.00
|-
! scope="row"| 12
| '''Ultrasonic Sensors'''
| [https://www.amazon.com/gp/product/B01COSN7O6/ ELEGOO HC-SR04 Ultrasonic Module]
| 5
| $12.00
|-
! scope="row"| 13
| '''GPS Antenna'''
| [https://www.amazon.com/dp/B07RRT615K/ GPS Antenna A1-UX]
| 1
| $10.98
|-
! scope="row"| 14
| '''PCB Fabrication'''
| [https://jlcpcb.com/ JLCPCB]
| 5
| $40.15
|-
! scope="row"| 15
| '''Miscellaneous'''
| [https://www.amazon.com Amazon],[https://www.mouser.com/ Mouser Electronics],[https://www.digikey.com/ Digikey],[https://anchor-electronics.com/ Anchor Electronics]
| ~
| $48.07
|-
! scope="row"|
|
|
| '''Total'''
| '''$1036.15'''
|-

|}

 

== '''Printed Circuit Board''' ==

=== Design And Architecture ===
The complete PCB (for boards and hardware peripherals) was designed using EasyEDA online software. The 4 nodes will be communicating via CAN bus and other peripherals are connected to the PCB via headers.

=== Power Section===
We have 2 power banks supplying our system. And the Servo Motor, RPM sensor and DC rear Motor (via ESC) are powered using LiPo battery (6 volts).
* Power bank #1 - Subset 2

* Power bank #2 - Subset 1, Subset 3, Bluetooth

'''NOTE:'''

'''Subset 1:'''
1. LIDAR
2. LCD
3. Compass

'''Subset 2:'''
1. Motor node
2. Driver node
3. BS node

'''Subset 3:'''
1. Geo node
2. Back ultrasonic sensor

=== Fabrication ===
* PCB was sent to fabrication to JLCPCB China which provided PCB with MOQ of 5 and 2 layers of PCB with common grounded the entire copper area.
'''DRC elements'''
* Track Width = 12
* Clearance = 10
* Via Diameter = 24
* Via Drill Diameter = 12

=== Challenges ===
* Auto-routing gave lot of challenges (only ~60% success) and sometimes the online server even crashes and faces downtime. Even local routing had lot of issues. So make sure to plan your design accordingly.
* We started our PCB design well ahead of the project. So lot of pre-planning had to be done with regard to final hardware and placement of components in order to avoid spending extra time and money while re-ordering.
* The PCB went through a lot of internal revisions even before placing order. This was time-consuming.

'''Other hardware challenges:'''
* Figuring out why various hardware peripherals (GPS, Bluetooth, LIDAR and Ultrasonic sensor) started to malfunction (devices were on but values were either inconsistent / not occurring), took a lot of time to debug. It was due to insufficient power.

 

[[File:CMPE243 S20 T2 EasyEDA.png|1040x1200px|thumb|center|PCB Layout Design in EasyEDA]]
[[File:CMPE243 S20 T2 PCB SCHEMATIC.jpg|1041x550px|thumb|center|PCB Schematic]]

<div><ul>
<li style="display: inline-block;"> [[File:CMPE243 S20 T2 PCBFRONT.jpg|thumb|none|600px|PCB Top Layer]] </li>
<li style="display: inline-block;"> [[File:CMPE243 S20 T2 PCBBACK.jpg|thumb|none|600px|PCB Bottom Layer]] </li>
</ul></div>

 

== '''CAN Communication''' ==
<Talk about your message IDs or communication strategy, such as periodic transmission, MIA management, etc.>

=== Hardware Design ===
<Show your CAN bus hardware design>

=== DBC File ===

DBC FILE: [https://gitlab.com/coder137/can-ster_truck/-/blob/dbc-improvements/projects/lpc40xx_freertos/project.dbc Gitlab]

<pre>
VERSION ""

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

BS_:

BU_: DBG DRIVER IO MOTOR SENSOR GEO

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" GEO,MOTOR,SENSOR

BO_ 101 GEO_HEARTBEAT: 1 GEO
SG_ GEO_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,MOTOR,SENSOR

BO_ 102 MOTOR_HEARTBEAT: 1 MOTOR
SG_ MOTOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,SENSOR

BO_ 103 SENSOR_HEARTBEAT: 1 SENSOR
SG_ SENSOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,MOTOR

BO_ 200 MOTOR_STEERING: 1 DRIVER
SG_ MOTOR_STEERING_direction: 0|8@1- (1,0) [-2|2] "" MOTOR

BO_ 210 DRIVER_COORDINATES: 8 DRIVER
SG_ DRIVER_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
SG_ DRIVER_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 220 MOTOR_SPEED: 1 DRIVER
SG_ MOTOR_SPEED_processed: 0|8@1- (1,0) [-3|3] "" MOTOR

BO_ 300 GEO_DEGREE: 8 GEO
SG_ GEO_DEGREE_current: 0|32@1+ (0.000001,0) [0|360] "degrees" DRIVER
SG_ GEO_DEGREE_required: 32|32@1+ (0.000001,0) [0|360] "degrees" DRIVER

BO_ 310 GEO_DESTINATION_REACHED: 1 GEO
SG_ GEO_DESTINATION_REACHED_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 400 MOTOR_SPEED_FEEDBACK: 4 MOTOR
SG_ MOTOR_SPEED_current: 0|32@1+ (0.1,0) [0|60] "kph" DRIVER

BO_ 500 SENSOR_BT_COORDINATES: 8 SENSOR
SG_ SENSOR_BT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
SG_ SENSOR_BT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 510 SENSOR_SONARS: 8 SENSOR
SG_ SENSOR_SONARS_left: 0|21@1+ (0.001,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right: 21|21@1+ (0.001,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle: 42|21@1+ (0.001,0) [0|0] "cm" DRIVER

BO_ 520 SENSOR_LIDAR: 8 SENSOR
SG_ SENSOR_LIDAR_middle: 0|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_slight_left: 16|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_slight_right: 32|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_back: 48|16@1+ (1,0) [0|0] "cm" DRIVER

BO_ 530 MOTOR_KEY: 1 SENSOR
SG_ MOTOR_KEY_val: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 900 GEO_CURRENT_COORDINATES: 8 GEO
SG_ GEO_CURRENT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" DBG
SG_ GEO_CURRENT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" DBG

BO_ 901 GEO_DISTANCE_FROM_DESTINATION: 4 GEO
SG_ GEO_distance_from_destination: 0|32@1+ (0.001,0) [0|0] "meters" DBG

BO_ 902 MOTOR_INFO_DBG: 4 MOTOR
SG_ MOTOR_INFO_DBG_rps: 0|16@1+ (1,0) [0|0] "" DBG
SG_ MOTOR_INFO_DBG_pwm: 16|16@1+ (0.001,0) [0|0] "" DBG

BO_ 903 LIPO_BATTERY_VOLTAGE_DBG: 4 MOTOR
SG_ LIPO_BATTERY_VOLTAGE_val: 0|32@1+ (0.01,0) [0|0] "volts" DBG

BO_ 904 CURRENT_CHECKPOINT_DBG: 1 GEO
SG_ CURRENT_CHECKPOINT_val: 0|8@1+ (1,0) [0|0] "" DBG

CM_ "--BU (Network Node) Information--";
CM_ BU_ DRIVER "The driver controller of the car";
CM_ BU_ GEO "The geo controller of the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";

CM_ "--BO (Message) Information--";
CM_ BO_ 100 "Driver Sync message used to synchronize the controllers";
CM_ BO_ 101 "Geo Sync message used to synchronize the controllers";
CM_ BO_ 102 "Motor Sync message used to synchronize the controllers";
CM_ BO_ 103 "Sensor Sync message used to synchronize the controllers";

CM_ BO_ 200 "Steering direction values sent by Driver Node to Motor Node";
CM_ BO_ 210 "Driver Destination coordinates sent by Driver Node";
CM_ BO_ 220 "Required motor speed computed from Driver Node to Motor Node";

CM_ BO_ 300 "Current and computer/required degree values sent by Geo Node";
CM_ BO_ 310 "Indicator signal to check if the RC car has reached the destination";

CM_ BO_ 400 "Current motor info (rps and kph) sent as feedback to the Driver Node";

CM_ BO_ 500 "Coordinate BT values (destination coordinates) sent by Sensor Node";
CM_ BO_ 510 "LIDAR - Distance from obstacle detected in each sector";
CM_ BO_ 520 "Ultrasonic Sensor - Distance from obstacle detected by each sensor";
CM_ BO_ 530 "Start/Stop signal from the Bluetooth app";

CM_ BO_ 900 "Destination coordinates for BUSMASTER debugging";
CM_ BO_ 901 "Distance from destination";
CM_ BO_ 902 "Supplied PWM value to the motor and its RPM";
CM_ BO_ 903 "LIPO Battery Voltage";
CM_ BO_ 904 "Current checkpoint of the car";

CM_ "--SG (Signal) Information for Heartbeats--";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver node";
CM_ SG_ 101 GEO_HEARTBEAT_cmd "Heartbeat command from the geological node";
CM_ SG_ 102 MOTOR_HEARTBEAT_cmd "Heartbeat command from the motor node";
CM_ SG_ 103 SENSOR_HEARTBEAT_cmd "Heartbeat command from the sensor node";

CM_ "--SG (Signal) Information for DRIVER Node--";
CM_ SG_ 200 DRIVER_STEERING_direction "Calculated Driver Steering values (-2,2) for Motor";
CM_ SG_ 210 DRIVER_COORDINATES_latitude "Destination Latitude coordinate";
CM_ SG_ 210 DRIVER_COORDINATES_longitude "Destination Longitude coordinate";
CM_ SG_ 220 MOTOR_SPEED "Calculated Driver speed values (-3,3) for Motor";

CM_ "--SG (Signal) Information for GEO Node--";
CM_ SG_ 300 GEO_DEGREE_current "Current Geo Degree relative to true north";
CM_ SG_ 300 GEO_DEGREE_required "Calculated Geo Degree computed by Haversine Formula";
CM_ SG_ 310 GEO_DESTINATION_REACHED "Indicator signal to check if the RC car has reached the destination";

CM_ "--SG (Signal) Information for MOTOR Node--";
CM_ SG_ 400 MOTOR_SPEED_FEEDBACK "Feedback speed (kph) sent by Motor Node";

CM_ "--SG (Signal) Information for SENSOR Node--";
CM_ SG_ 500 SENSOR_BT_COORDINATES_latitude "Destination Latitude received over Bluetooth";
CM_ SG_ 500 SENSOR_BT_COORDINATES_longitude "Destination Longitude received over Bluetooth";
CM_ SG_ 510 SENSOR_SONARS_left "Ultrasonic Sensor attached to the left side";
CM_ SG_ 510 SENSOR_SONARS_right "Ultrasonic Sensor attached to the right side";
CM_ SG_ 510 SENSOR_SONARS_middle "Ultrasonic Sensor attached to the middle";
CM_ SG_ 510 SENSOR_SONARS_back_left "Ultrasonic Sensor attached to the back left side";
CM_ SG_ 510 SENSOR_SONARS_back_right "Ultrasonic Sensor attached to the back right side";
CM_ SG_ 520 SENSOR_LIDAR_middle "Lidar sensing the middle sector (-15 to 15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_left "Lidar sensing the slight left sector (-45 to -15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_right "Lidar sensing the slight right sector (15 to 45 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_back "Lidar sensing the back of the car (165 to 195 degrees)";
CM_ SG_ 530 MOTOR_KEY_val "1 -> Start the motor from the app, 0 -> Stop";

CM_ SG_ 900 GEO_CURRENT_COORDINATES_latitude "Current Latitude";
CM_ SG_ 900 GEO_CURRENT_COORDINATES_longitude "Current Longitude";
CM_ SG_ 901 GEO_distance_from_destination "Distance from destination";
CM_ SG_ 902 MOTOR_INFO_DBG_rps "Current RPS value of the motor";
CM_ SG_ 902 MOTOR_INFO_DBG_pwm "Supplied motor PWM value";
CM_ SG_ 903 LIPO_BATTERY_VOLTAGE_val "LIPO Battery Voltage";
CM_ SG_ 904 CURRENT_CHECKPOINT_val "Current checkpoint of the car";

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

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

BA_ "GenMsgCycleTime" BO_ 100 1000;
BA_ "GenMsgCycleTime" BO_ 200 50;
BA_ "FieldType" SG_ 100 DRIVER_HEARTBEAT_cmd "DRIVER_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 102 GEO_HEARTBEAT_cmd "GEO_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 103 MOTOR_HEARTBEAT_cmd "MOTOR_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 104 SENSOR_HEARTBEAT_cmd "SENSOR_HEARTBEAT_cmd";

BA_ "FieldType" SG_ 200 MOTOR_STEERING "MOTOR_STEERING";
BA_ "FieldType" SG_ 230 MOTOR_SPEED_val "MOTOR_SPEED_val";
BA_ "FieldType" SG_ 310 GEO_DESTINATION_REACHED_cmd "GEO_DESTINATION_REACHED_cmd";

VAL_ 100 DRIVER_HEARTBEAT_cmd 2 "DRIVER_HEARTBEAT_cmd_REBOOT" 1 "DRIVER_HEARTBEAT_cmd_SYNC" 0 "DRIVER_HEARTBEAT_cmd_NOOP" ;
VAL_ 101 GEO_HEARTBEAT_cmd 2 "GEO_HEARTBEAT_cmd_REBOOT" 1 "GEO_HEARTBEAT_cmd_SYNC" 0 "GEO_HEARTBEAT_cmd_NOOP";
VAL_ 102 MOTOR_HEARTBEAT_cmd 20 "MOTOR_HEARTBEAT_cmd_REBOOT" 10 "MOTOR_HEARTBEAT_cmd_SYNC" 0 "MOTOR_HEARTBEAT_cmd_NOOP" ;
VAL_ 103 SENSOR_HEARTBEAT_cmd 200 "SENSOR_HEARTBEAT_cmd_REBOOT" 100 "SENSOR_HEARTBEAT_cmd_SYNC" 0 "SENSOR_HEARTBEAT_cmd_NOOP" ;

VAL_ 200 MOTOR_STEERING_direction -2 "MOTOR_STEERING_hard_left" -1 "MOTOR_STEERING_slight_left" 0 "MOTOR_STEERING_straight" 1 "MOTOR_STEERING_slight_right" 2 "MOTOR_STEERING_hard_right";
VAL_ 220 MOTOR_SPEED_processed -3 "MOTOR_SPEED_reverse_fast" -2 "MOTOR_SPEED_reverse_medium" -1 "MOTOR_SPEED_reverse_slow" 0 "MOTOR_SPEED_neutral" 1 "MOTOR_SPEED_forward_slow" 2 "MOTOR_SPEED_forward_medium" 3 "MOTOR_SPEED_forward_fast";
VAL_ 310 GEO_DESTINATION_REACHED_cmd 1 "GEO_DESTINATION_REACHED_cmd_REACHED" 0 "GEO_DESTINATION_REACHED_cmd_NOT_REACHED";
</pre>

 

== '''Motor Controller''' ==
<Picture and link to Gitlab>

This controller is used to control the components of the car-related to motor. We can control the speed and steering of the car having interfaced with various components with the SJ-2 board. The servo motor is controlled via PWM and is used to set the steering direction of the car. The DC motor is controlled by the Electronic Speed Controller (ESC) via PWM for speed. We read the speed of the car by using an RPM sensor. By using the RPM sensor values, a feedback loop has been designed to regulate the speed of the car. A state machine has been designed to manage the forward and backward movements of the car.
Additionally, a voltage divider circuit has been implemented to read the battery voltage. All motor functionality and CAN message communication is run at 10 Hz.

=== Hardware Design ===

The following diagram details the hardware implementation of the motor module with the SJTwo board:
Hardware Interface
- Servo Motor
The servo motor responds to PWM pulses. It has three pins namely Vcc, PWM Input Signal, and GND. The servo is powered using 6V from the car battery. Based on the PWM signal supplied from the SJTwo board the front wheels are turned.
- Electronic Speed Controller (ESC)
The ESC is used to control the DC motor. It is supplied power using the 7.4 V LiPo battery. It has three pins namely Vout, PWM Input Signal, and GND. Based on the PWM input signal, the speed and forward, neutral, and backward movements of the car is changed. Vout is given to the RPM sensor and Servo motor.
- DC Motor
The DC motor is controlled using the ESC. It has two pins, a positive and negative terminal. A PWM signal wire is connected to the microcontroller and the required current is provided by the LiPo battery and the ESC. The DC motor is controlled using PWM at 10Hz.

[[File:CMPE243_S20_T2_Canster_Truck_Motor_Hardware.png|thumb|center|750px| Motor Hardware System]]

Note: First calibrate the DC motor or the motor will not respond to your PWM pulses. For help with calibration go to this [https://traxxas.com/support/Programming-Your-Traxxas-Electronic-Speed-Control website]

- RPM Sensor

The RPM sensor is used to get the current speed of the car. We use the info for creating a feedback loop (PID) for maintaining the speed of the car in uphill and downhill situations. The RPM sensor mounts on the rear DC motor shaft compartment with a special assembly also provided by Traxxas. The magnet which attached to the inner gear generates a pulse each rotation. The sensor works on the hall effect principle where it provides a current across its terminal when placed in a magnet's field. The RPM sensor has three pins namely Vcc, Signal, and GND.

- Battery Voltage Divider Circuit
- (Need Niket’s help)

=== Software Design ===

The software for the motor node was divided into multiple files and made modular to improve readability and understanding of the complex logic involved. The main code modules are for:
• Servo Motor
• Electronic Speed Controller
• RPM Sensor
• Motor Wrapper
• Battery Voltage

The motor wrapper module is used to wrap all the code from the esc, servo, and rpm modules into simple to use functions to be called in the periodic tasks.
• Servo Motor
It uses the steering value sent from the driver (-2 to 2) and matches it to the appropriate PWM value for steering. This code module is run at 10Hz.
<pre>
void servo__steer_processor(int16_t steering_value) {
switch (steering_value) {
case MOTOR_STEERING_hard_left:
servo__steer_hard_left();
break;
case MOTOR_STEERING_slight_left:
servo__steer_soft_left();
break;
case MOTOR_STEERING_straight:
servo__steer_straight();
break;
case MOTOR_STEERING_slight_right:
servo__steer_soft_right();
break;
case MOTOR_STEERING_hard_right:
servo__steer_hard_right();
break;
default:
printf("\nDid not receive steering value");
}
}
</pre>
• Electronic Speed Controller

This code module is used to control the DC motor. It receives the motor direction value from the driver and sets the appropriate PWM value. Based on the value the motor is commanded to move the car forward or backwards. A switch case is implemented to set PWM values for movement in different directions along with different speeds.
<pre>
void esc__direction_processor(int16_t direction_value) {
desired_direction_value = direction_value;
switch (direction_value) {
case MOTOR_SPEED_reverse_fast:
esc__reverse_fast();
break;
case MOTOR_SPEED_reverse_medium:
esc__reverse_medium();
break;
case MOTOR_SPEED_reverse_slow:
esc__reverse_slow();
break;
case MOTOR_SPEED_neutral:
esc__neutral();
break;
case MOTOR_SPEED_forward_slow:
esc__forward_slow();
break;
case MOTOR_SPEED_forward_medium:
esc__forward_medium();
break;
case MOTOR_SPEED_forward_fast:
esc__forward_fast();
break;

default:
printf("\nDid not receive direction and speed value");
}
}
</pre>

There is also a feedback loop to control the speed. The ESC code depends on the rpm sensor code for the current speed values.
<pre>
double current_speed = get_speed_kph();
double desired_speed = desired_speed_kph;
float adjusted_duty_cycle = 0.0;
adjusted_duty_cycle = duty_cycle + (speed_to_pwm_adjustment(desired_speed, current_speed));
</pre>

[[File:CMPE243_S20_T2_Canster_Truck_Motor1.png|thumb|center|400px| Motor Flowchart 1]]

• RPM Sensor
This code module is used to get current speed data from the RPM sensor. It is based on interrupts. When the wheel rotates once, we get one pulse due to the magnet installed. This pulse generates a falling edge interrupt during which we increment the pulse counter. Since, this code is run at 1Hz we collect the number of pulses generated every one second. This gives us the number of rotations per second using which we can calculate the speed in kph.
<pre>
float rpm__calculate_speed_kph() {
uint16_t rotation_per_sec = pulse_count;
pulse_count = 0;
speed_kph = ((CIRCUMFERENCE_METER * rotation_per_sec) * (MPS_TO_KPH_CONVERSION_FACTOR)) / GEAR_RATIO;
return speed_kph;
}
</pre>

• Motor Wrapper
As mentioned above, the main function of this code module is to wrap all the other code modules and call the right functions at the appropriate frequency. The motor wrapper code also includes a state machine for ensuring a smooth transition between forward to backward state and vice versa. In order to achieve a smooth transition, a series of PWM pulses must be generated at the right time. For example, when the motor is moving from forward to backward state, a reverse value must be given first followed by at least three neutral values, and then continue with reverse values.

[[File:CMPE243_S20_T2_Canster_Truck_Motor2.png|thumb|center|400px| Motor Flowchart 2]]

=====LIPO Battery Voltage=====
The LIPO Battery Voltage was calculated using ADC in Burst Mode. A LIPO Hardware module was created for the same which contained two functions, <code>lipo__init</code> and <code>lipo__get_voltage</code>.

The voltage divider circuit is stepped down from 7.4V to 2.1V using 10K and 4K Resistor pair.

'''LIPO Initialization'''

The LIPO Initialization phase initializes the ADC, Enables Burst mode on the ADC pins and configures the Alternate Function Registers for the same.

'''LIPO Get Voltage'''

We read the raw ADC value from the LPC Hardware register. This value will be from 0 - 3.3V. However due to our voltage divider configuration the max voltage that we should theoretically get is 2.1V. This means that 2.1V corresponds to 7.4V of the LIPO Battery voltage.

The formula used is
<code>(raw_adc_value * MAX_LIPO_BATTERY_VOLTAGE_VALUE) / MAX_LIPO_ADC_VALUE</code>

=== Technical Challenges ===
<ol>
<li>Changing movements of the car from Forward to Backward and vice versa
If you just change the PWM value from say 16 (Forward) to 14(Backward), the DC motor will just stop and will not make wheels turn reverse. We discovered this problem quite late as during the initial testing we had always run the car from the start with either forward or reverse but never tried changing the direction during run-time.
Solution: The motor requires a series of PWM pulses which is specific to the car to transition from forward mode to reverse mode. In our case we had to give the PWM pulses in the following sequence. Suppose,
<ol>
<li> Forward (16) (callback_count=0)</li>
<li> Forward (16) (callback_count =1)</li>
<li> Reverse (14) (callback_count =2)</li>
<li> Neutral (15) (callback_count = 3)</li>
<li> Neutral (15) (callback_count = 4)</li>
<li> Neutral (15) (callback_count = 5)</li>
<li> Reverse (14) (callback_count = 6)</li>
<li> Continue reverse</li>
</ol>
Similarly, the reverse to forward can also be implemented.
<li>DC motor shooting off when there is an improper ground connection
When we connected the battery voltage circuit for reading the voltage from the battery, the motor would randomly shoot off every now and then.
Solution: Connect the voltage divider circuit to the common ground rather than taking the ground from the ESC.</li>
</ol>

<HR>
 

== '''Geological Controller''' ==

<Picture and link to Gitlab>

===Messages===
*GEO_HEARTBEAT: Used to check for MIA by other nodes. Highest priority message for GEO Node

*GEO_DEGREE: Sends the current degree relative to the North Pole computed by the Compass and the Required degree relative to the North Pole computed by Bearing Angle using the Current Coordinate and Destination Coordinate.

*GEO_DESTINATION_REACHED: Sets a flag, 0 for destination not reached and 1 for destination reached

*GEO_CURRENT_COORDINATES: Debug Message used to send the Current GPS Coordinates

*GEO_DISTANCE_FROM_DESTINATION: Debug message used to send the Distance from Destination

*CURRENT_CHECKPOINT_DBG: Debug message used to check which checkpoint is being navigated to

=== Hardware Design ===

[[File:CMPE243_S20_T2_GEO1.png|thumb|center|650px| Geological Diagram]]

=== Software Design ===
=====Overview=====
*Inside the `periodic_callback__initialize`
**Initialize the CAN BUS
**Initialize the GPS

*Inside the `periodic_callback__1hz`
**Handle all MIA (from other Nodes)
**Update GPS LED when init and in case of failure
**Compute the GEOLOGIC for Waypoints algorithm once every second (1000 ms)

*Inside the `periodic_callback__10hz`
**Handle CAN Incoming messages (Decode)
**Transmit CAN Geo messages (Encode and send)
**Compute the GPS Coordinate

=====Compass I2C Driver=====
An online datasheet resource was used to work with the Compass (https://www.robot-electronics.co.uk/htm/cmps11i2c.htm)
Initially the Compass I2C Driver was tested using the Terminal I2C Helper built by our Professor Preetpal Kang. Using this resource we were quickly able to read various I2C Registers and display it onto the terminal.

For our project the only required part of the Compass was the 16-bit Compass Bearing value (0-3599) i.e 0-359.9 degree values. These values were stored in the 2nd and 3rd register (Register 2 being the High Byte).
Once the raw data was received over I2C we could easily combine the data

<pre>
uint16_t bearing_value = (Reg2 << 8) | Reg3;
float rval = bearing_value / 10.0;
return rval;
</pre>
The returned value were transmitted to the Driver Node to compute its steering based on the required Bearing Angle.

=====GPS Initialization=====
GPS Initialization activates the Hardware GPIO (RX and TX), FreeRTOS Queue for UART Interrupts (UART Module) and Line Buffer Module to parse each GPS line.

=====GPS Data Parsing=====
The GPS Hardware module transmits an NMEA string over UART to the SJTwo Board. We read each character one by one and add it to the Line Buffer module.
Inside its computation loop, the Line Buffer module checks if a newline character has been received.
When a newline character has been received the entire string is extracted from the line buffer module and parsed according to its identifier ($GPRMC, $GPGGA) received and parsed into individual tokens.
For our purposes the $GPRMC NMEA string was the most appropriate and it helped us extract the Current Latitude Longitude as well as the Valid/Invalid tag for the Canster Truck.

=====GPS LED Indication for debugging=====

A simple module that checks for the GPRMC GPS Message and extracts the A or V valid (Tag). If $GPRMC NMEA string is valid, LED is set, else LED is reset. This gives us onsite debugging capabilities to know if GPS has locked onto a satellite signal.

=====GEO Logic Module Computation=====
The GEO Logic Module computes the Bearing Angle, Haversine Distance as well as the Waypoints algorithm.

'''Bearing Angle:'''

<code>
θ = atan2( sin Δλ ⋅ cos φ2 , cos φ1 ⋅ sin φ2 − sin φ1 ⋅ cos φ2 ⋅ cos Δλ )
</code>

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

Since atan2 returns values in the range -π ... +π (that is, -180° ... +180°), to normalize the result to a compass bearing (in the range 0° ... 360°, with −ve values transformed into the range 180° ... 360°), convert to degrees and then use (θ+360) % 360, where % is (floating point) modulo.
For final bearing, simply take the initial bearing from the endpoint to the start point and reverse it (using θ = (θ+180) % 360).

The above article reference gives us the required bearing angle that our car must align itself to, to reach a particular destination coordinate from its current coordinate.
The Steering of the Canster Truck depends on the above-computed angle values.

'''Haversine Distance Formula:'''

This uses the ‘haversine’ formula to calculate the great-circle distance between two points – that is, the shortest distance over the earth’s surface – giving an ‘as-the-crow-flies’ distance between the points (ignoring any hills they fly over, of course!).

<code>
a = sin²(Δφ/2) + cos φ1 ⋅ cos φ2 ⋅ sin²(Δλ/2)

c = 2 ⋅ atan2( √a, √(1−a) )

d = R ⋅ c
</code>

where φ is latitude, λ is longitude, R is earth’s radius (mean radius = 6,371km);
note that angles need to be in radians to pass to trig functions!

The above formula is used to calculate the distance between the source coordinate (received via GPS) and the destination coordinate.
Later this was used to compute the distance between source coordinate and each individual checkpoint to traverse the shortest distance.

'''Waypoints Algorithm:'''

The Waypoints algorithm that was chosen was a slightly modified version of Djikstra’s Algorithm.
3 values were calculated before the final computation

* Distance between source and final destination (DISTsd)
* Distance between source and each individual checkpoint (DISTsc)
* Distance between each individual checkpoint and the final destination. (DISTcd)

If '''DISTsd''' was lesser than '''DISTcd''', this checkpoint was discarded (we continue in the loop). Since we would be moving in the opposite direction, rather than towards the final destination.

If '''DISTsd''' was greater than '''DISTcd''', then we checked the nearest checkpoint to the source.
The minimum value was set initial that was equal to '''DISTsd'''.

If '''DISTsc''' was lesser than the minimum value stored, '''DISTsc''' would become the new minimum value, and the checkpoint index and coordinates would be appropriately stored and returned from the function.

In this way we would navigate to the nearest checkpoint from the source, while also making sure NOT to travel in the opposite direction.
This logic is recomputed only when we reach the checkpoint selected and the algorithm runs again to find the next checkpoint that we need to navigate to.

=====CAN Decode Destination Coordinates=====
Destination Coordinates are received from the Bridge and Sensor Node and transmitted over the CAN Bus. The value is decoded and stored in the GEO Logic Module.
This is a very important value since our entire GEO Logic calculations are based on the Destination Coordinate.

=====CAN Encode and Send=====

The main messages that were transmitter are
#Geo Degree
#Geo Destination Reached
#Distance from Destination Debug and Checkpoint Index debug

'''Geo Degree Computation as per Waypoints Algorithm:'''

Geo Degree was computed as per the current coordinates and the most recently computed checkpoint coordinates. This bearing angle calculation w.r.t computed checkpoint would continue till we do not reach that particular checkpoint.
Once we reach the computed checkpoint, Waypoint algorithm is recomputed as per the process mentioned above and the algorithm runs again.

'''Geo Destination Reached:'''

An Area of around 4 meters was set around the destination coordinate to check if the destination had been reached.
This measurement was taken into consideration to allow for the loss in precision when transmitting data over CAN as well as any irregularities that might occur when getting values from the GPS.
Having an area of 4 meters was very accurate for all of our test runs.

'''Geo Distance from Destination Debug and Checkpoint Index Debug:'''

Getting debug information was very critical to speed up our development process. In this case we could actively see if our algorithm worked properly.
The Geo Distance from Destination was used to see if we were moving closer to our destination or veering further away from it.
The Checkpoint Index was used to see which checkpoint index we were traveling to. By knowing the placements of the Individual checkpoints we could manually as well as programmatically (via Android application) verify the working of our Canster Truck.

=== Technical Challenges ===
#DBC Challenge for GEO Coordinates -> Could not encode more than 5-6 decimal places at a time, on later investigation we found that the 10000 is an int value, however 100000 overflows the int value.
#Creating an efficient algorithm for Waypoints, O(n) complexity.
#Getting appropriate fixes for GPS when not in a completely open space.
#GPS used to fluctuate or stop giving values when Battery voltage went below a particular threshold. Always supply 3.3V constantly at a good amperage.

<HR>
 

== '''Sensor [Bridge and Sensor Controller]''' ==
<Picture and link to Gitlab>

==='''Ultrasonic Sensor'''===
====Hardware Design====
This sensor uses an ultrasonic beam to measure the distances. Based on the time taken between when the beam is sent and received back to the sensor, the distance is calculated in the node.
Apart from 5v and GND, this sensor has 2 pins ECHO and TRIG which are interfaced with the SJ-Two board via GPIO.

[[File:CMPE243_S20_T2_CansterTruck_ultrasonic_sensor.jpg|thumb|center|300px| Ultrasonic Sensor Diagram]]

====Software Design====
* Init the GPIO pin connected to TRIG of the sensor as output and for ECHO as an input port.
* Attach the interrupt on the ECHO input port.
* Store the system_clock_count before setting the trigger pulse and then set the pulse. Also keep monitoring the input port.
* Take the system_clock_count at the instant of receiving the interrupt.
Distance = (system_clock_count_at_trig - system_clock_count_after_at_echo) / 57.14

==='''Lidar Sensor'''===
====Hardware Design====
The RPLidar sensor can be powered from a 5-volt source and uses UART communication to receive commands and transmit data. It has seven pins to interface with. Two sets of the pins (four total) are for power and ground. The remaining three are for UART receive and transmit, and for making the lidar’s motor spin.

[[File:CMPE243_S20_T2_Canster_Truck_RPLidar_A1.JPG|thumb|center|300px| RPLidar A1]]

====Software Design====
In terms of the lidar, the SJ2 initializes GPIO, UART, and memory for storing the measurement values. After initialization, the command to begin scanning is sent. Here, we wait for the lidar to send a response packet, letting the host (SJ2 board) know it received the command. The response packet the lidar sends will be 7 bytes. If the correct 7 bytes are not received, the command will be sent again.

[[File:CMPE243_S20_T2_Canster Truck_Lidar_flow.jpeg|thumb|center|200px| Lidar Flow]]

Following the response packet, the lidar begins sending 5-byte measurement data. Each sample contains a distance measurement (in millimeters) and the angle (with respect to the lidar) in which it was taken. The data packet structure is shown in the following figure. In addition to containing the distance and angle, the packet includes a quality value, to indicate the reliability of the measurement, and three check bits (S, ~S, and C). As the data is received via UART, we wait until we have 5 bytes before continuing to process. Before processing the 5 bytes after receiving them, the check bits are confirmed to be correct. If they are incorrect, it will not be processed and we will wait for another sample to be received.

[[File:CMPE243_S20_T2_Canster Truck_DataPacketStructure.JPG|thumb|center|200px| Data Packet Structure]]

In the case the sample is correct, each measurement value that is in a direction of interest will be placed in an array designated to one of four directions (left, right, front, rear). Each of these directions have their own sector in the lidar’s 360-degree view.
*Right sector: 11°-30°
*Rear sector: 170°-190°
*Left sector: 330°-349°
*Front sector: 350°-370° (or 10°)

The arrays mentioned will hold roughly 20 measurements, which are every degree in the sector. In the event, objects are too far to measure, the lidar will report 0 mm. distance. Since there is no measurable obstacle, a “large” distance value of 3000 mm. is placed in the array. The smallest distance value will be taken from each array and reported to the driver node for obstacle avoidance.

=== Technical Challenges ===
====Ultrasonic====
====Lidar====
*'''Datasheet not 100% clear:''' The correct datasheet for the was a bit difficult to obtain, and the manufacturer needed to be contacted. The first document found online was high level and general information about the sensor, but the manufacturer did provide another document that contained the information of the commands and responses to and from the lidar, and their packet structure. The documents did not clearly state the angles with respect to the lidar are fixed, which left me wondering if the lidar will think the direction it is facing when powered on will become the new “zeroth” angle.

*'''UART Buffer Overflow:''' When first interfacing with the sensor, the incoming bytes of the lidar were printed on to the terminal to make sure there was a response and to make sense of the information. Since the command we sent results in 5 bytes of data per measurement samples from the lidar and the lidar measured 2000 times per second, there are will be roughly 10k Bytes per second of data incoming that need to be handled continuously. With an improperly sized UART buffer and print statements it is guaranteed to occur, making the lidar data look like random values.

*'''Proper Parsing of Measurement Data:''' After sending a command to the lidar, the sensor will send a response packet, followed by the measurement data. The initial response from the lidar is a 7-byte packet, followed by continuous 5-byte measurement samples. I needed to make sure however I handled the response would be independent of how the measurement is handled, so as not to create a potential unwanted offset when receiving measurements.

*'''Object Detection with Received Data:''' Once proper communication was set up with the lidar and measurement data was getting decoded, there needed to be a way to measure when obstacles were present. If ~360 measurements are handled entirely independently from one another, it could become a complex and confusing code. To achieve a simple approach, four sectors about 20 degrees in size were used to represent the front, left, right, and rear directions.

*'''Bugs in Code:''' When first implementing the code, there were a few bugs from typos, incorrect numbers, and some faulty logic that were found with the use of unit testing. Unit testing helped find these issues and verified the logic was correct, and I would say gave me 90% confidence in my lidar handling.

<HR>
 

== '''Bridge [Bridge and Sensor Controller]'''==
<Picture and link to Gitlab>

Bridge functionality of the Bridge and Sensor Controller is to establish wireless communication between the SJ-2 Board and the android mobile device using the HC-05 Bluetooth module. The Bridge controller will be receiving start command with destination GEO coordinates and stop command. The Bridge controller will be transmitting the required sensor data and debug information to be displayed on the android application.

[[File:CMPE243_S20_T2_BRIDGE.png|thumb|center|500px| Bridge Diagram]]

===Bluetooth===

==== Software Design ====

'''Low-Level Layer'''

In this layer, similar to the GPS the UART GPIO was initialized (RX, TX), FreeRTOS Queue was initialized for UART Interrupts and the line buffer module was initialized to parse strings.

Two basic functions <code>bt__read</code> and <code>bt__write</code> were implemented.
As the name suggested, <code>bt__write</code> took a string as its input parameter and transmitted that data to the Android application. <code>bt__read</code> stored the incoming characters into the line buffer, parsed the line received into its identifier and tokens, and invoked a callback function.

Since this was a low-level layer the User would not be directly invoking this library. Instead a '''Bluetooth Wrapper''' module was created which would be invoked and used by the user.

'''Application Layer'''

The Bluetooth Wrapper module had the appropriate <code>read_once</code> and <code>write_once</code> functions.

The <code>read_once</code> function internally just called the <code>bt__read</code> function. All of the decodings was done inside the Callback Function.
To get the Destination coordinate the string received from the Android Application was in the form of
<code>$loc,<destination_latitude>,<destination_longitude>.</code>
Upon receiving this data we parsed the destination_latitude and destination_longitude, which could later be accessed using getters.
We also set a start flag to notify the Driver Node that destination has been received and we can start steering towards our checkpoints.

Another command implemented was the stop command.
<code>$stop</code>
This was used to send a stop flag to the Driver node.

The <code>write_once</code> function used the getter methods from each CAN Decode message and update its internal state variables. A CSV String was created using the <code>$canster</code> identifier and various debugging points were appended to this message using a comma.
On the Android application side this CSV string was tokenized and displayed onto the Application Debug screen appropriately.

==== Technical Challenges ====

<List of problems and their detailed resolutions>

<HR>
 

== '''Driver [Driver and LCD Controller]''' ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===

[[File:CMPE243_S20_T2_Canster Truck_Driver_Flowchart.png|thumb|center|750px|Driver Flowchart]]

The above block diagram explains the process flow of obstacle detection for the car. The LIDAR detects
the obstacle and depending on the distance of obstacle the car takes a slight right and slight left or a
hard right and hard left. The state of the car also depends on the value of the LIDAR and ultrasonic sensor.
The loose ends of the LIDAR for the reverse condition are checked by the ultrasonic sensors. The
The ultrasonic sensor works on the principle of trigger and echo and can detect the obstacles very close by.
The range of the Ultrasonic sensor is lower than the LIDAR. Finally, if no obstacle is detected the car goes
straight until the destination is reached. The speed of the car is also various when an obstacle is detected to
avoid the crash and the car’s smooth transition from one state to another. The key to the android
application controls the start and stop the process of the car. If the key is not pressed, then the stays in the

neutral state. The speed of the car is controlled by the changing duty cycle of the input voltage. There
are seven-speed levels in which the motor can run on. These speed levels are Forward Slow, Medium,
Fast, Reverse Slow, Medium, Fast, and Neutral. The Neutral is the stop condition with a 0% duty cycle.

=== Technical Challenges ===

< List of problems and their detailed resolutions>

<HR>
 

== '''LCD [Driver and LCD Controller]''' ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
The GLCD used was created by 4DSystems, using their IDE a UI was created. Each UI component could be controlled by sending UART data targeted at the widget address.
The best part about this GLCD was that we had a lot of interactive widgets to display debugging information in real-time.
The GLCD code was divided into 3 parts:
<ol>
<li>'''Low-Level Initialization'''
Initialize the low-level hardware interfaces to send and receive data from the GLCD.
Similar to the GPS and Bluetooth, The UART GPIO was initialized (RX, TX), FreeRTOS Queue was initialized for UART Interrupt and line buffer was used to get a stream of data for parsing.

Low-level '''read''' and '''write''' commands were used as per the working of the GLCD Module.
When Reading data pertaining to a widget on the GLCD we would need to send a particular response packet.
<pre>
void lcd__read(lcd_object_e object_id, uint8_t object_index, uint8_t *response, uint16_t *response_data) {

uint8_t checksum = READ_OBJ ^ object_id ^ object_index;
uint8_t buffer[] = {READ_OBJ, object_id, object_index, checksum};

lcd__write_data(buffer, sizeof(buffer) / sizeof(uint8_t));
lcd__read_response_id(response);
lcd__read_response_data(response_data);
}
</pre>

The response_data returned contains the Widget ID as well as the current value stored on that widget.

When Writing data pertaining to a widget on a GLCD the process is similar to the above mentioned code.
<pre>
void lcd__write(lcd_object_e object_id, uint8_t object_index, uint8_t msb, uint8_t lsb, uint8_t *response) {
uint8_t checksum = WRITE_OBJ ^ object_id ^ object_index ^ msb ^ lsb;
uint8_t buffer[] = {WRITE_OBJ, object_id, object_index, msb, lsb, checksum};

lcd__write_data(buffer, sizeof(buffer) / sizeof(uint8_t));
lcd__read_response_id(response);
}
</pre>

However in this case we receive only an ACK or NACK from the system. ACK would mean that the write to GLCD widget was successful and the widget now stored appropriate values. NACK would mean that a particular error has occurred. The errors could be regarding baud rate, incorrect bit format, incorrect index values, etc.
</li>
<li>'''GLCD Wrapper for Widgets'''
The above low-level code had generic read and write functions. However for our UI we were only using 3 Widgets. All of which had '''different Indexes''' and '''Widget IDs'''.
Therefore a very simple library was created to easily interface with those widgets
<pre>
bool lcd_wrapper__read_led(uint8_t index);
uint16_t lcd_wrapper__read_meter(uint8_t index);
uint16_t lcd_wrapper__read_leddigit(uint8_t index);

bool lcd_wrapper__write_led(uint8_t index, bool value);
bool lcd_wrapper__write_meter(uint8_t index, uint16_t value);
bool lcd_wrapper__write_leddigit(uint8_t index, uint16_t value);
</pre>

The above code is self-explanatory read and write functions for '''LED''', '''METER''', and '''LED DIGIT'''.
</li>
<li>'''GLCD UI'''
Now that we had our low level and Widget wrapper working properly, we wanted to create our Dynamic UI as well. The code would need to be robust enough to handle any UI that we create on the GLCD which could be reflected equivalently in our C Code.

<pre>
static void lcd_ui__update_ui(void) {

lcd_wrapper__write_led(LCD_LED_DRIVER_MIA_INDEX, driver_mia_led);
lcd_wrapper__write_led(LCD_LED_SENSOR_MIA_INDEX, sensor_mia_led);
lcd_wrapper__write_led(LCD_LED_GEO_MIA_INDEX, geo_mia_led);
lcd_wrapper__write_led(LCD_LED_MOTOR_MIA_INDEX, motor_mia_led);

// kph is always in the range of 0 - 10
lcd_wrapper__write_meter(LCD_METER_KPH_INDEX, kph_meter % 11);

// These will be in the Range of 0-99
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_RPM_INDEX, rpm_leddigit % 100);
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_CURRENTDEGREE_INDEX, cdegree_leddigit % 100);
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_REQUIREDDEGREE_INDEX, rdegree_leddigit % 100);
}
</pre>

As we can see the `lcd_ui__update_ui` function was called periodically inside the 1Hz function. It updated the screen in real time based on the static values that were stored AND updated inside the LCD UI module.
The Constant INDEX values stored were directly mapped onto the Index values were received from the 4DWorkshop UI Software.
</li>
</ol>

=== Technical Challenges ===

< List of problems and their detailed resolutions>

<HR>
 

== '''Android Application''' ==
[https://gitlab.com/akhilcherukuri/can-ster_truck_application Gitlab]
=== Software Design ===

<div><ul>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android1.jpg|thumb|none|250px|Splash Screen]]</li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android2.jpg|thumb|none|250px|Main Activity Screen]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android3.jpg|thumb|none|250px|Map Activity Screen]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android4.jpg|thumb|none|250px|Info Activity Screen 1]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android5.jpg|thumb|none|250px|Info Activity Screen 1]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android6.jpg |thumb|none|250px|Debug Activity Screen]]</li>
</ul></div>

The application consists of a total of 5 Activities:

*'''Main Activity:'''
**This is the app launch display screen
**It will check for all the required permission onStart().
**Has search button for connecting from a paired device list view
**Once device is clicked, an intent will start the Map Activity
*'''Map Activity:'''
** For this requirement we are using the Google Maps Fragment, for the map fragment to function we must request an API key from Google and set the key in the manifest of the application.
** Destination marker(Red Marker) is set using setOnMapClickListener to which the car will navigate to, the destination can be changed by clicking elsewhere on the Map Fragment. The marker can be removed using setOnMarkerClickListener.
** When the start button is pressed, the start command identifier along with destination latitude and longitude is sent to the car via the write thread. A background thread is started along with it to indicate the current car's position(Green Marker) along with a plotline between the current position and destination.
** When the stop button is pressed, the stop command identifier is sent to the car, to stop and turn off the car.
*'''Info Activity:'''
** Messages from Geological, Driver, Motor coming from CAN bus are decoded by the Sensor and Bridge controller and sent to the Android application as a string.
** The received string is parsed and categorizes the data to store it in the required textView to be displayed.
** Bluetooth status, Lidar Values, Ultrasonic Sensor Values, Motor Speed, Motor RPM, Motor PWM, Cars' current location, Compass Heading, Distance till Destination, Checkpoint Index is displayed. This was useful for debugging purposes and allowed us to avoid scanning the mounted LCD or CAN Busmaster on PC during drives.
*'''Debug Activity:'''
**The main function of this activity is to check all RAW RX and RAW TX messages and create a log of all the data received and sent.
*'''Bluetooth Connection Service Activity''' :
**This is the background activity that handles all the threads required for transmission and receiving data using Bluetooth connections. It has 3 running threads which is called inside other activities using a handler:
** Accept Thread - Listens to BluetoothServerSocket using listenUsingRfcommWithServiceRecord. In order for the RF communication socket to connect to the HC-05, we used the following UUID: 00001101-0000-1000-8000-00805F9B34FB. This is a generic SSP Bluetooth UUID that enables the socket to directly connected to HC-05 and maintain the connection.
** Connect Thread - Creates a Bluetooth socket using createRfcommSocketToServiceRecord
** Connected Thread - Creates socket.getInputStream(); and socket.getOutputStream(); when bytes are available in input stream it will read them into a buffer.
***All messages for activities are done by Handler mHandler.obtainMessage(); mHandler.sendMessage();

*'''Receieved string''':
** A String is sent to the Bluetooth app from HC-05 and when it receives a string with identifier "$canster", the message is prased accordingly by using the string delimiter ',' and is ended by the newline character '\n' which will remove the data from StringBuffer.
** Example: $canster,37.339334,-121.881123,37.338713,-121.880685,10.123,20.133,30.123,10.5,88.1,99.2,-2,1,44,7,11,22,33,-3,23\n

[[File:CMPE243_S20_T2_BLUETOOTHFLOWCHART.png|thumb|center|650px| Android Application Flowchart]]

=== Technical Challenges ===

<HR>
 

== '''Mangaement''' ==
===Team Management ===
===Git Management===

Git Management amongst 6 team members was definitely a very challenging task. Depending on our initial design we could’ve had a lot of merge conflicts. However those risks were mitigated by spending a LOT of time in the initial stages to decide our pipeline and structure.

<li>There are certain components in our system that were COMMON. For example the CAN initialization, communication and decodes were all similar for the most part between all the 4 Controllers. The utility modules used were also similar in nature</li>
<li>Thus we made a common branch that contained the templates for CAN Nodes (not Controllers), Hardware code and Utility functions.
<ol>
<li>Later this common branch was forked into an individual Controller specific branch (SENSOR, GEO, MOTOR or DRIVER).</li>
<li>Only the Logic folder contained Controller specific code, specific to that controller.</li>
</ol>
<li>This gave us a lot of flexibility since all the team members had similar APIs to work with on all 4 branches. This promoted easy understanding and learning.
<ol>
<li>Many team members frequently worked on 2 or more controllers at a time where can messages were concerned. Having a APIs also meant that just the can_handler needed to be updated regularly followed by the equivalent logic code. </li>
<li>Inside the logic folder, getters to the can node modules were frequently used.</li></ol>
<pre>
├───can_module
│ ├───can_bus_initializer
│ ├───can_constants
│ ├───can_driver_node
│ ├───can_geo_node
│ ├───can_handler
│ ├───can_motor_node
│ ├───can_sensor_node
│ └───test
├───hardware
│ ├───bt
│ ├───compass
│ ├───gps
│ ├───lcd
│ ├───test
│ └───ultrasonic
├───logic
│ ├───driver_obstacle
│ ├───driver_state
│ ├───geo_logic
│ └───test
├───periodics
│ └───test
└───utility
├───line_buffer
└───test
</pre>

'''Challenges'''
<li>It was initially a bit of a learning curve to understand the flow of the repository</li>
<li>When using a git management system with different versions in each branch it became very tough when the number of branches suddenly exploded in size. A lot of relevant code was stuck in a lot of different branches.
<ol>
<li>This happened mainly due to assignment submissions and unclosed MRs that eventually became stale.</li>
<li>Our strategy was to abandon these MRs and keep forking from these branches without merging it back into its final controller branch.</li>
<li>The latest branches that were kept were aptly named `<controller>_bleeding_edge_dev` branches since they were never merged back from where they were forked.</li>
</ol>
<li>Since a lot of our code also depended on the DBC autogenerated code, we could not suddenly change the DBC Message names once they were established since it caused a change in the Struct name that was generated and used.
<ol>
<li>Our solution to this was to keep everything backward compatible. We added new function names without deleting old DBC messages.</li>
<li>In certain places where we wanted to modify a function name it was done one by one so that a lot of the code is not broken at one time.</li>
</ol>
<li>Common Branches eventually became stale as our progress continued on the bleeding edge branches
<ol>
<li>For example certain GPS features needed to be added which were done on the GEO_bleeding_edge_dev branch but never pushed or cherry-picked back into the COMMON branch.</li>
<li>This was a similar issue to our 2nd point but manageable since the goal of the COMMON branch was to provide a template for further work and nothing more.</li>
<li>At the end of the day each controller is its own Individual Project and while the messages between them are same. The Hardware code does not need to be same.</li>
<li>This also prompted team-members to ask if we could delete unused hardware or logic file code (which wasn’t being used and was imported from the template). This was also fine and can be done during cleanup stage. However we eventually got used to the Modular system of our project so much so that we did not worry about the additional modules that were present in each branched controller project.</li>
</ol>

<HR>
 

== '''Conclusion''' ==
CMPE243 gives one of the best experiences one could ever get in their academic life. The course is designed to give an insight into how the industry functions and enhances both technical and management skills. Apart from learning how to work and implement application of CAN protocol, one can get a hands-on experience with version control, unit-testing and software design. Overall it was a very great journey.

=== Project Video ===

=== Project Source Code ===

=== Advise for Future Students ===
'''GENERAL:'''
* Form your team and start the project as early as you can.
* Clearly discuss what role each individual should do and ensure that progress is regularly tracked so that the team doesn't fall back on any schedule.
* Since lot of code and hardware integration is involved with this project, make sure testing is thoroughly and periodically done and make note of all the issues found.
'''HARDWARE:'''
* Decide on how you would power up the peripherals. We had issues with Bluetooth (not connecting), GPS (lock not happening) and LIDAR (giving incorrect values). After lot of cycles of hardware and software debugging, we found that the issue was with power. Choose wisely as to which peripherals must be connected to which power bank.
* PCB design is time consuming as there is a lot of hardware components involved and a huge responsibility falls on the designer to know the about each component. Coordinating with multiple team members and verifying with them if their respective hardware is correct takes a lot of time. So start well ahead.
* Make sure to expose some extra GPIO and GND pins for future use.
'''MOTOR:'''
*You can use the LiPo battery to power the RPM and servo motor instead of using a separate power source. Use Vout from the ESC to get 6V.
*Start the PID control calibration early on as you will need to do extensive testing to get it working.

=== Acknowledgement ===
<HR>
Firstly we would like to express our gratitude to Professor Preetpal Kang for his guidance throughout the semester and providing us with this opportunity. We would also like to thank the ISA members Vignesh Kumar Venkateshwar and Aakash Vrajlal Chitroda for being available whenever in need and guiding us to complete the project.

== '''References''' ==

===Motor Controller===
===Geological Controller===
* Movable Scripts: [https://www.movable-type.co.uk/scripts/latlong.html Calculate distance, bearing and more between Latitude/Longitude points]
* CMPS11:[https://www.robot-electronics.co.uk/htm/cmps11i2c.htm I2C Configuration]

===Bridge and Sensor Controller===
===Driver and LCD Controller===
*LCD Software: [https://4dsystems.com.au/ulcd-32ptu 4Dsystems]
===Android===
*Youtube Channel: [https://www.youtube.com/channel/UCoNZZLhPuuRteu02rh7bzsw Coding with Mitch]
*Android Developers: [https://developer.android.com/guide/topics/connectivity/bluetooth Website][https://github.com/googlearchive/android-BluetoothChat Github]
*Udemy Course: [https://www.udemy.com/course/the-complete-android-oreo-developer-course/ Complete Android Oreo Developer Course]
===PCB Design===
*EDC Tool: [https://easyeda.com/ EasyEDA]

S20: Canster Truck

2020-05-22T05:48:04Z

Proj user22: /* GEO Logic Module Computation */

[[File:CMPE243_S20_T2_Canster_Truck_Logo.png|thumb|455px|caption|right|CAN-STER TRUCK LOGO]]

== '''Abstract''' ==
'''The Canster Truck Project is an autonomous RC car with CAN Bus interfaced controllers. The development of the RC car's subsystem modules (Interfacing of Ultrasonic Sensor, LIDAR, Bluetooth, GPS, Compass and CAN modules) was divided among six team members. The aim of the project is to develop an autonomous RC Car which can navigate from one source location to the selected destination on the app by avoiding obstacles in its path using sensors. Waypoints algorithm is used as the path finding technique.'''

 

== '''Introduction and Objectives''' ==

'''The project was divided into 7 modules:'''

* '''Bridge and Sensor Controller'''
* '''Motor Controller'''
* '''Geological Controller'''
* '''Driver and LCD Controller'''
* '''Hardware Integration'''
* '''Android Application'''
* '''Testing & Code Review'''

'''RC Car Objectives'''
'''1. Driver and LCD Controller''' - Handles algorithms for obstacle avoidance, route maneuvering, and waypoints
'''2. Geological Controller''' - Recieves coordinates from GPS and Heading from Compass for navigation
'''3. Motor Controller''' - Controls movements of the RC Car
'''4. Bridge and Sensor Controller''' - Detects surrounding objects and interfaces android application to controller via bluetooth
'''Team Objectives'''

[[File:CMPE243_S20_T2_High_Level_System_Diagram.png|thumb|center|800px| High Level System Diagram]]

 

== '''Team Members and Responsibilities''' ==

'''Gitlab Project Link''' - [https://gitlab.com/coder137/can-ster_truck '''Canster Truck''']
 

*'''Niket Naidu''' [https://www.linkedin.com/in/niket-naidu-30090a134/ LinkedIn] [https://gitlab.com/coder137 Gitlab]
** '''Geological Controller''' : Waypoint Algorithm, Haversine and Bearing Angle logic
** '''Driver and LCD Controller''' : GLCD
** '''Bridge and Sensor Controller''' : Bluetooth
** '''Testing & Code Review'''

*'''Ganesh Ram Pamadi''' [https://www.linkedin.com/in/ganeshram93/ LinkedIn] [https://gitlab.com/ganeshram2493 Gitlab]
** '''Hardware Integration'''
** '''Testing & Code Review'''
** '''Driver Controller'''
** '''Motor Controller'''

*'''Nikhil Pabbisetty''' [https://www.linkedin.com/in/nikhilpabbisetty/ LinkedIn] [https://gitlab.com/nikhilpeoria Gitlab]
** '''Bridge and Sensor Controller'''
** '''Motor Controller'''

*'''Akhil Cherukuri''' [https://www.linkedin.com/in/akhilcherukuri/ LinkedIn] [https://gitlab.com/akhilcherukuri Gitlab] [https://github.com/akhilcherukuri Github]
** '''Android Application'''
** '''Bridge and Sensor Controller'''

*'''Ashish Anant Ladage''' [https://www.linkedin.com/in/ashish-anant-ladage-7bb3a214b/ LinkedIn] [https://gitlab.com/ashishladage1 Gitlab]
** '''Driver and LCD Controller'''
** '''Hardware Integration'''
** '''Motor Controller'''

*'''Jesus De Haro De Reza''' [https://www.linkedin.com/in/jesus-de-haro-66342424/ LinkedIn] [https://gitlab.com/deharo27 Gitlab]
** '''Bridge and Sensor Controller'''
** '''Motor Controller'''

 

== '''Administrative Responsibilities''' ==
* '''Team Lead''' - [https://www.linkedin.com/in/niket-naidu-30090a134/ '''Niket Naidu''']
* '''Git Repository Manager''' - [https://www.linkedin.com/in/niket-naidu-30090a134/ '''Niket Naidu''']
* '''Bill Of Materials Manager''' - [https://www.linkedin.com/in/akhilcherukuri '''Akhil Cherukuri''']
* '''Wiki Report Manager''' - [https://www.linkedin.com/in/akhilcherukuri '''Akhil Cherukuri''']

 

== '''Schedule''' ==

{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-

! scope="row"| '''1'''
| style="text-align:center;" |'''02/11/2020'''
| style="text-align:center;" |'''02/17/2020'''
|
*'''Form teams and decide group name'''
*'''Review past projects'''
*'''Slack: Create project group and invite Preet'''
*'''GitLab: Create project groups repository'''
*'''Analysis of component required'''

|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''2'''
| style="text-align:center;" |'''02/18/2020'''
| style="text-align:center;" |'''02/24/2020'''
|
*'''Study CAN Communication'''
*'''Create Bill of Materials'''
*'''Order RC Car'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''3'''
| style="text-align:center;" |'''02/25/2020'''
| style="text-align:center;" |'''03/02/2020'''
|
*'''Setup team finance management using Splitwise application'''
*'''Complete Bill of Materials'''
*'''Order all other required components'''
*'''Wikipedia: Setup project report template'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''4'''
| style="text-align:center;" |'''03/03/2020'''
| style="text-align:center;" |'''03/09/2020'''
|
*'''Read the respective datasheets and manuals for each component'''
*'''Test each component for working conditions'''
|
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''5'''
| style="text-align:center;" |'''03/10/2020'''
| style="text-align:center;" |'''03/16/2020'''
|
*'''Assign team responsibilities and roles'''
*'''Setup team project management environment (ClickUp)'''
*'''Define CAN DBC'''
*'''Research GPS antennas and order'''
*'''Android: Environmental setup of Android Studio and enable version control'''
*'''Hardware : Decide PCB editing software (easyEDA)'''
*'''Hardware : Draft schematic for required PCB design'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''6'''
| style="text-align:center;" |'''03/17/2020'''
| style="text-align:center;" |'''03/23/2020'''
|
*'''Hardware : Create model of PCB''' 
*'''Android: Add a Button for changing bluetooth connection status in the application''' 
*'''Geological: Interface Compass module with SJ-2 board using I2C interface''' 
*'''Geological: Interface GPS module with SJ-2 board using the UART interface''' 
*'''Geological: Parse raw data to get meaningful values for GPS and Compass''' 
*'''Sensor: Interface and check the functionality of ultrasonic sensors to the SJ-2 board''' 
*'''Motor: Interface of Servo & DC motor to the SJ-2 board and check for basic functionality''' 
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''7'''
| style="text-align:center;" |'''03/24/2020'''
| style="text-align:center;" |'''03/30/2020'''
|
*'''Hardware : Finalize components placement on PCB.''' 
*'''Motor: Add PWM functionality and test the code on DC and servo motors''' 
*'''Sensor: Interface and check and study the output readings of Lidar sensor with SJ-2 board over UART''' 
*'''LCD Display: Explore UI designing of LCD''' 
*'''Hardware: Finalize on optimal ultrasonic sensor placements''' 
*'''Android: Initiate Bluetooth communication and show staus via text view''' 
*'''Wikipedia: Establish final wiki schedule'''
*'''Complete CAN communication format for each controller and link DBC file to the Wiki'''
*'''Complete high-level system block diagram'''
*'''Complete unit-level block diagrams'''
*'''Bridge: Interface HC-5 bluetooth module with Sj-2 board using serial communicaton'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''8'''
| style="text-align:center;" |'''03/31/2020'''
| style="text-align:center;" |'''04/06/2020'''
|
*'''Hardware: Analyze PCB model and order PCB Circuit board''' 
*'''Android: Initiate Bluetooth communication and send "Hello World".''' 
*'''Wikipedia: Start adding information/images/diagrams to the relevant sections'''
*'''Motor: Configure ESC for correct speed outcome according to frequency & PWM values''' 
*'''Motor: Finish RPM sensor hardware and software implementation and integration''' 
*'''Sensor: Read output from Lidar and setup structure for outputting for DBC''' 
*'''Geological: Implement waypoints algorithm''' 
*'''Driver: Implement obstacle avoidance algorithm''' 
*'''Bridge: Pass data such as "Hello World" from HC-05 bluetooth module to bluetooth terminal android application'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''9'''
| style="text-align:center;" |'''04/07/2020'''
| style="text-align:center;" |'''04/13/2020'''
|
*'''Hardware: Remove Unused parts from RC Car''' 
*'''Hardware: Mount PCB and 3D Parts''' 
*'''Motor: Decide different cut-off values from sensor to command right /slight right/ straight/ slight left/ left to motor.''' 
*'''Android: Embed Google Maps API for setting the car's destination.''' 
*'''LCD: Work to show RC cars live status information(battery level, current speed, long, lat, bearing, sensor data, etc)''' 
*'''Driver: Test obstacle avoidance algorithm and fine-tune sensor readings''' 
*'''Geological: Test checkpoint algorithm''' 
*'''Bridge: Establish two way communication between android application and bluetooth module''' 
*'''Update Bill of Materials for miscellaneous hardware'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''10'''
| style="text-align:center;" |'''04/14/2020'''
| style="text-align:center;" |'''04/20/2020'''
|
*'''Hardware: Integrate all hardware modules''' 
*'''LCD: Testing & Validation of the LCD UI and display vehicle status information''' 
*'''Android: Send car location to the app and checkpoints received to Geo module''' 
*'''Motor: Optimize PID control by accelerating/decelerating as instructed by Driver''' 
*'''Bridge: Configure HC-05 for auto reconnection if bluetooth communication disconnects''' 
*'''Add multiple debug messages and transmit on CAN'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''11'''
| style="text-align:center;" |'''04/21/2020'''
| style="text-align:center;" |'''04/27/2020'''
|
*'''Android: Send additional vehicle status information from RC car to the Application for display''' 
*'''Android: Finalize User Interface Design and Icon''' 
*'''Continuously test the whole system and handling of corner cases (outside).'''
*'''Finalize RC Car For Project Proto 1'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''12'''
| style="text-align:center;" |'''04/28/2020'''
| style="text-align:center;" |'''05/04/2020'''
|
*'''Gitlab: Push final code'''
*April 28th: Project Proto 1
*'''Finalize RC Car for Project Demo'''
*May 1st: Project Presentation
*'''Finalize RC Car for Project Proto 2'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''13'''
| style="text-align:center;" |'''05/05/2020'''
| style="text-align:center;" |'''05/21/2020'''
|
* '''Complete Individual Contribution Peer Grading'''
* '''Review and Complete Wiki Project Page'''
|
*'''Completed'''
*'''In Progress'''
|-
|}

 

== '''Bill Of Materials''' ==
{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Item#
! scope="col"| Part Description
! scope="col"| Part Model & Vendor
! scope="col"| Quantity
! scope="col"| Cost in USD
|-
! scope="row"| 1
| '''Microcontroller Boards'''
| SJ2 Boards (Purchased from Preet Kang)
| 4
| $200.00
|-
! scope="row"| 2
| '''CAN Transceivers'''
| [https://www.waveshare.com/sn65hvd230-can-board.htm Waveshare SN65HVD230]
| 12
| $54.48
|-
! scope="row"| 3
| '''RC Car'''
| [https://www.amazon.com/Traxxas-Slash-Course-2-4GHZ-Vehicle/dp/B01DU474B0/ref=sr_1_3?ie=UTF8&qid=1474747759&sr=8-3&keywords=Traxxas+1%2F10+slash+2wd Traxxas 2WD RTR with 2.4Ghz Radio]
| 1
| $260.00
|-
! scope="row"| 4
| '''Lithium-Ion Battery'''
| [https://www.rcsuperstore.com/traxxas-7600mah-2s-7-4v-25c-id-lipo-battery-pack/ Traxxas 7600mAh 2S 7.4V 25C iD LiPo Battery Pack]
| 1
| $75.00
|-
! scope="row"| 5
| '''Lithium-Ion Battery Charger'''
| [https://www.amazon.com/Traxxas-2970-EZ-Peak-Charger-Identification/dp/B00OAFYLJC/ref=pd_bxgy_21_img_2?ie=UTF8&psc=1&refRID=JVX791WVV9Y8T9DW92KW Traxxas 2970 EZ-Peak Plus 4-Amp NiMH/LiPo Fast Charger]
| 1
| $50.00
|-
! scope="row"| 6
| '''Compass Breakout Board'''
| [https://www.dfrobot.com/product-1275.html DFRobot CMPS11 Compass]
| 1
| $29.99
|-
! scope="row"| 7
| '''Bluetooth Breakout Board'''
| [https://www.amazon.com/HC-05-Bluetooth-Pass-through-Wireless-Communication/dp/B01G9KSAF6/ref=sr_1_4?ie=UTF8&qid=1507077325&sr=8-4&keywords=arduino+bluetooth+hc-05 DSD TECH Bluetooth HC-05]
| 1
| $8.49
|-
! scope="row"| 8
| '''LIDAR Sensor'''
| [https://www.amazon.com/RPLiDAR-A1M8-Degree-Laser-Scanner/dp/B07H7X3SFF/ref=sr_1_fkmrnull_1?crid=2FSUI76G4UA8K&keywords=rplidar+a1m8+-+360+degree+laser+scanner+development+kit&qid=1552764172&s=gateway&sprefix=RPlidar%2Caps%2C263&sr=8-1-fkmrnull SEEED STUDIO RPLIDAR A1M8]
| 1
| $109.99
|-
! scope="row"| 9
| '''RPM Sensor'''
| [https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM Traxxas 6520 RPM Sensor]
| 1
| $13.70
|-
! scope="row"| 10
| '''GPS Breakout Board'''
| [https://www.adafruit.com/product/746 Adafruit Ultimate GPS Breakout v3]
| 1
| $44.30
|-
! scope="row"| 11
| '''LCD Display'''
| [https://4dsystems.com.au/ulcd-32ptu 4Dsystems 3.2 TFT-LCD ULCD-32PTU]
| 1
| $79.00
|-
! scope="row"| 12
| '''Ultrasonic Sensors'''
| [https://www.amazon.com/gp/product/B01COSN7O6/ ELEGOO HC-SR04 Ultrasonic Module]
| 5
| $12.00
|-
! scope="row"| 13
| '''GPS Antenna'''
| [https://www.amazon.com/dp/B07RRT615K/ GPS Antenna A1-UX]
| 1
| $10.98
|-
! scope="row"| 14
| '''PCB Fabrication'''
| [https://jlcpcb.com/ JLCPCB]
| 5
| $40.15
|-
! scope="row"| 15
| '''Miscellaneous'''
| [https://www.amazon.com Amazon],[https://www.mouser.com/ Mouser Electronics],[https://www.digikey.com/ Digikey],[https://anchor-electronics.com/ Anchor Electronics]
| ~
| $48.07
|-
! scope="row"|
|
|
| '''Total'''
| '''$1036.15'''
|-

|}

 

== '''Printed Circuit Board''' ==

=== Design And Architecture ===
The complete PCB (for boards and hardware peripherals) was designed using EasyEDA online software. The 4 nodes will be communicating via CAN bus and other peripherals are connected to the PCB via headers.

=== Power Section===
We have 2 power banks supplying our system. And the Servo Motor, RPM sensor and DC rear Motor (via ESC) are powered using LiPo battery (6 volts).
* Power bank #1 - Subset 2

* Power bank #2 - Subset 1, Subset 3, Bluetooth

'''NOTE:'''

'''Subset 1:'''
1. LIDAR
2. LCD
3. Compass

'''Subset 2:'''
1. Motor node
2. Driver node
3. BS node

'''Subset 3:'''
1. Geo node
2. Back ultrasonic sensor

=== Fabrication ===
* PCB was sent to fabrication to JLCPCB China which provided PCB with MOQ of 5 and 2 layers of PCB with common grounded the entire copper area.
'''DRC elements'''
* Track Width = 12
* Clearance = 10
* Via Diameter = 24
* Via Drill Diameter = 12

=== Challenges ===
* Auto-routing gave lot of challenges (only ~60% success) and sometimes the online server even crashes and faces downtime. Even local routing had lot of issues. So make sure to plan your design accordingly.
* We started our PCB design well ahead of the project. So lot of pre-planning had to be done with regard to final hardware and placement of components in order to avoid spending extra time and money while re-ordering.
* The PCB went through a lot of internal revisions even before placing order. This was time-consuming.

'''Other hardware challenges:'''
* Figuring out why various hardware peripherals (GPS, Bluetooth, LIDAR and Ultrasonic sensor) started to malfunction (devices were on but values were either inconsistent / not occurring), took a lot of time to debug. It was due to insufficient power.

 

[[File:CMPE243 S20 T2 EasyEDA.png|1040x1200px|thumb|center|PCB Layout Design in EasyEDA]]
[[File:CMPE243 S20 T2 PCB SCHEMATIC.jpg|1041x550px|thumb|center|PCB Schematic]]

<div><ul>
<li style="display: inline-block;"> [[File:CMPE243 S20 T2 PCBFRONT.jpg|thumb|none|600px|PCB Top Layer]] </li>
<li style="display: inline-block;"> [[File:CMPE243 S20 T2 PCBBACK.jpg|thumb|none|600px|PCB Bottom Layer]] </li>
</ul></div>

 

== '''CAN Communication''' ==
<Talk about your message IDs or communication strategy, such as periodic transmission, MIA management, etc.>

=== Hardware Design ===
<Show your CAN bus hardware design>

=== DBC File ===

DBC FILE: [https://gitlab.com/coder137/can-ster_truck/-/blob/dbc-improvements/projects/lpc40xx_freertos/project.dbc Gitlab]

<pre>
VERSION ""

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

BS_:

BU_: DBG DRIVER IO MOTOR SENSOR GEO

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" GEO,MOTOR,SENSOR

BO_ 101 GEO_HEARTBEAT: 1 GEO
SG_ GEO_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,MOTOR,SENSOR

BO_ 102 MOTOR_HEARTBEAT: 1 MOTOR
SG_ MOTOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,SENSOR

BO_ 103 SENSOR_HEARTBEAT: 1 SENSOR
SG_ SENSOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,MOTOR

BO_ 200 MOTOR_STEERING: 1 DRIVER
SG_ MOTOR_STEERING_direction: 0|8@1- (1,0) [-2|2] "" MOTOR

BO_ 210 DRIVER_COORDINATES: 8 DRIVER
SG_ DRIVER_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
SG_ DRIVER_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 220 MOTOR_SPEED: 1 DRIVER
SG_ MOTOR_SPEED_processed: 0|8@1- (1,0) [-3|3] "" MOTOR

BO_ 300 GEO_DEGREE: 8 GEO
SG_ GEO_DEGREE_current: 0|32@1+ (0.000001,0) [0|360] "degrees" DRIVER
SG_ GEO_DEGREE_required: 32|32@1+ (0.000001,0) [0|360] "degrees" DRIVER

BO_ 310 GEO_DESTINATION_REACHED: 1 GEO
SG_ GEO_DESTINATION_REACHED_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 400 MOTOR_SPEED_FEEDBACK: 4 MOTOR
SG_ MOTOR_SPEED_current: 0|32@1+ (0.1,0) [0|60] "kph" DRIVER

BO_ 500 SENSOR_BT_COORDINATES: 8 SENSOR
SG_ SENSOR_BT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
SG_ SENSOR_BT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 510 SENSOR_SONARS: 8 SENSOR
SG_ SENSOR_SONARS_left: 0|21@1+ (0.001,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right: 21|21@1+ (0.001,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle: 42|21@1+ (0.001,0) [0|0] "cm" DRIVER

BO_ 520 SENSOR_LIDAR: 8 SENSOR
SG_ SENSOR_LIDAR_middle: 0|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_slight_left: 16|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_slight_right: 32|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_back: 48|16@1+ (1,0) [0|0] "cm" DRIVER

BO_ 530 MOTOR_KEY: 1 SENSOR
SG_ MOTOR_KEY_val: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 900 GEO_CURRENT_COORDINATES: 8 GEO
SG_ GEO_CURRENT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" DBG
SG_ GEO_CURRENT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" DBG

BO_ 901 GEO_DISTANCE_FROM_DESTINATION: 4 GEO
SG_ GEO_distance_from_destination: 0|32@1+ (0.001,0) [0|0] "meters" DBG

BO_ 902 MOTOR_INFO_DBG: 4 MOTOR
SG_ MOTOR_INFO_DBG_rps: 0|16@1+ (1,0) [0|0] "" DBG
SG_ MOTOR_INFO_DBG_pwm: 16|16@1+ (0.001,0) [0|0] "" DBG

BO_ 903 LIPO_BATTERY_VOLTAGE_DBG: 4 MOTOR
SG_ LIPO_BATTERY_VOLTAGE_val: 0|32@1+ (0.01,0) [0|0] "volts" DBG

BO_ 904 CURRENT_CHECKPOINT_DBG: 1 GEO
SG_ CURRENT_CHECKPOINT_val: 0|8@1+ (1,0) [0|0] "" DBG

CM_ "--BU (Network Node) Information--";
CM_ BU_ DRIVER "The driver controller of the car";
CM_ BU_ GEO "The geo controller of the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";

CM_ "--BO (Message) Information--";
CM_ BO_ 100 "Driver Sync message used to synchronize the controllers";
CM_ BO_ 101 "Geo Sync message used to synchronize the controllers";
CM_ BO_ 102 "Motor Sync message used to synchronize the controllers";
CM_ BO_ 103 "Sensor Sync message used to synchronize the controllers";

CM_ BO_ 200 "Steering direction values sent by Driver Node to Motor Node";
CM_ BO_ 210 "Driver Destination coordinates sent by Driver Node";
CM_ BO_ 220 "Required motor speed computed from Driver Node to Motor Node";

CM_ BO_ 300 "Current and computer/required degree values sent by Geo Node";
CM_ BO_ 310 "Indicator signal to check if the RC car has reached the destination";

CM_ BO_ 400 "Current motor info (rps and kph) sent as feedback to the Driver Node";

CM_ BO_ 500 "Coordinate BT values (destination coordinates) sent by Sensor Node";
CM_ BO_ 510 "LIDAR - Distance from obstacle detected in each sector";
CM_ BO_ 520 "Ultrasonic Sensor - Distance from obstacle detected by each sensor";
CM_ BO_ 530 "Start/Stop signal from the Bluetooth app";

CM_ BO_ 900 "Destination coordinates for BUSMASTER debugging";
CM_ BO_ 901 "Distance from destination";
CM_ BO_ 902 "Supplied PWM value to the motor and its RPM";
CM_ BO_ 903 "LIPO Battery Voltage";
CM_ BO_ 904 "Current checkpoint of the car";

CM_ "--SG (Signal) Information for Heartbeats--";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver node";
CM_ SG_ 101 GEO_HEARTBEAT_cmd "Heartbeat command from the geological node";
CM_ SG_ 102 MOTOR_HEARTBEAT_cmd "Heartbeat command from the motor node";
CM_ SG_ 103 SENSOR_HEARTBEAT_cmd "Heartbeat command from the sensor node";

CM_ "--SG (Signal) Information for DRIVER Node--";
CM_ SG_ 200 DRIVER_STEERING_direction "Calculated Driver Steering values (-2,2) for Motor";
CM_ SG_ 210 DRIVER_COORDINATES_latitude "Destination Latitude coordinate";
CM_ SG_ 210 DRIVER_COORDINATES_longitude "Destination Longitude coordinate";
CM_ SG_ 220 MOTOR_SPEED "Calculated Driver speed values (-3,3) for Motor";

CM_ "--SG (Signal) Information for GEO Node--";
CM_ SG_ 300 GEO_DEGREE_current "Current Geo Degree relative to true north";
CM_ SG_ 300 GEO_DEGREE_required "Calculated Geo Degree computed by Haversine Formula";
CM_ SG_ 310 GEO_DESTINATION_REACHED "Indicator signal to check if the RC car has reached the destination";

CM_ "--SG (Signal) Information for MOTOR Node--";
CM_ SG_ 400 MOTOR_SPEED_FEEDBACK "Feedback speed (kph) sent by Motor Node";

CM_ "--SG (Signal) Information for SENSOR Node--";
CM_ SG_ 500 SENSOR_BT_COORDINATES_latitude "Destination Latitude received over Bluetooth";
CM_ SG_ 500 SENSOR_BT_COORDINATES_longitude "Destination Longitude received over Bluetooth";
CM_ SG_ 510 SENSOR_SONARS_left "Ultrasonic Sensor attached to the left side";
CM_ SG_ 510 SENSOR_SONARS_right "Ultrasonic Sensor attached to the right side";
CM_ SG_ 510 SENSOR_SONARS_middle "Ultrasonic Sensor attached to the middle";
CM_ SG_ 510 SENSOR_SONARS_back_left "Ultrasonic Sensor attached to the back left side";
CM_ SG_ 510 SENSOR_SONARS_back_right "Ultrasonic Sensor attached to the back right side";
CM_ SG_ 520 SENSOR_LIDAR_middle "Lidar sensing the middle sector (-15 to 15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_left "Lidar sensing the slight left sector (-45 to -15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_right "Lidar sensing the slight right sector (15 to 45 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_back "Lidar sensing the back of the car (165 to 195 degrees)";
CM_ SG_ 530 MOTOR_KEY_val "1 -> Start the motor from the app, 0 -> Stop";

CM_ SG_ 900 GEO_CURRENT_COORDINATES_latitude "Current Latitude";
CM_ SG_ 900 GEO_CURRENT_COORDINATES_longitude "Current Longitude";
CM_ SG_ 901 GEO_distance_from_destination "Distance from destination";
CM_ SG_ 902 MOTOR_INFO_DBG_rps "Current RPS value of the motor";
CM_ SG_ 902 MOTOR_INFO_DBG_pwm "Supplied motor PWM value";
CM_ SG_ 903 LIPO_BATTERY_VOLTAGE_val "LIPO Battery Voltage";
CM_ SG_ 904 CURRENT_CHECKPOINT_val "Current checkpoint of the car";

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

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

BA_ "GenMsgCycleTime" BO_ 100 1000;
BA_ "GenMsgCycleTime" BO_ 200 50;
BA_ "FieldType" SG_ 100 DRIVER_HEARTBEAT_cmd "DRIVER_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 102 GEO_HEARTBEAT_cmd "GEO_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 103 MOTOR_HEARTBEAT_cmd "MOTOR_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 104 SENSOR_HEARTBEAT_cmd "SENSOR_HEARTBEAT_cmd";

BA_ "FieldType" SG_ 200 MOTOR_STEERING "MOTOR_STEERING";
BA_ "FieldType" SG_ 230 MOTOR_SPEED_val "MOTOR_SPEED_val";
BA_ "FieldType" SG_ 310 GEO_DESTINATION_REACHED_cmd "GEO_DESTINATION_REACHED_cmd";

VAL_ 100 DRIVER_HEARTBEAT_cmd 2 "DRIVER_HEARTBEAT_cmd_REBOOT" 1 "DRIVER_HEARTBEAT_cmd_SYNC" 0 "DRIVER_HEARTBEAT_cmd_NOOP" ;
VAL_ 101 GEO_HEARTBEAT_cmd 2 "GEO_HEARTBEAT_cmd_REBOOT" 1 "GEO_HEARTBEAT_cmd_SYNC" 0 "GEO_HEARTBEAT_cmd_NOOP";
VAL_ 102 MOTOR_HEARTBEAT_cmd 20 "MOTOR_HEARTBEAT_cmd_REBOOT" 10 "MOTOR_HEARTBEAT_cmd_SYNC" 0 "MOTOR_HEARTBEAT_cmd_NOOP" ;
VAL_ 103 SENSOR_HEARTBEAT_cmd 200 "SENSOR_HEARTBEAT_cmd_REBOOT" 100 "SENSOR_HEARTBEAT_cmd_SYNC" 0 "SENSOR_HEARTBEAT_cmd_NOOP" ;

VAL_ 200 MOTOR_STEERING_direction -2 "MOTOR_STEERING_hard_left" -1 "MOTOR_STEERING_slight_left" 0 "MOTOR_STEERING_straight" 1 "MOTOR_STEERING_slight_right" 2 "MOTOR_STEERING_hard_right";
VAL_ 220 MOTOR_SPEED_processed -3 "MOTOR_SPEED_reverse_fast" -2 "MOTOR_SPEED_reverse_medium" -1 "MOTOR_SPEED_reverse_slow" 0 "MOTOR_SPEED_neutral" 1 "MOTOR_SPEED_forward_slow" 2 "MOTOR_SPEED_forward_medium" 3 "MOTOR_SPEED_forward_fast";
VAL_ 310 GEO_DESTINATION_REACHED_cmd 1 "GEO_DESTINATION_REACHED_cmd_REACHED" 0 "GEO_DESTINATION_REACHED_cmd_NOT_REACHED";
</pre>

 

== '''Motor Controller''' ==
<Picture and link to Gitlab>

This controller is used to control the components of the car-related to motor. We can control the speed and steering of the car having interfaced with various components with the SJ-2 board. The servo motor is controlled via PWM and is used to set the steering direction of the car. The DC motor is controlled by the Electronic Speed Controller (ESC) via PWM for speed. We read the speed of the car by using an RPM sensor. By using the RPM sensor values, a feedback loop has been designed to regulate the speed of the car. A state machine has been designed to manage the forward and backward movements of the car.
Additionally, a voltage divider circuit has been implemented to read the battery voltage. All motor functionality and CAN message communication is run at 10 Hz.

=== Hardware Design ===

The following diagram details the hardware implementation of the motor module with the SJTwo board:
Hardware Interface
- Servo Motor
The servo motor responds to PWM pulses. It has three pins namely Vcc, PWM Input Signal, and GND. The servo is powered using 6V from the car battery. Based on the PWM signal supplied from the SJTwo board the front wheels are turned.
- Electronic Speed Controller (ESC)
The ESC is used to control the DC motor. It is supplied power using the 7.4 V LiPo battery. It has three pins namely Vout, PWM Input Signal, and GND. Based on the PWM input signal, the speed and forward, neutral, and backward movements of the car is changed. Vout is given to the RPM sensor and Servo motor.
- DC Motor
The DC motor is controlled using the ESC. It has two pins, a positive and negative terminal. A PWM signal wire is connected to the microcontroller and the required current is provided by the LiPo battery and the ESC. The DC motor is controlled using PWM at 10Hz.

[[File:CMPE243_S20_T2_Canster_Truck_Motor_Hardware.png|thumb|center|750px| Motor Hardware System]]

Note: First calibrate the DC motor or the motor will not respond to your PWM pulses. For help with calibration go to this [https://traxxas.com/support/Programming-Your-Traxxas-Electronic-Speed-Control website]

- RPM Sensor

The RPM sensor is used to get the current speed of the car. We use the info for creating a feedback loop (PID) for maintaining the speed of the car in uphill and downhill situations. The RPM sensor mounts on the rear DC motor shaft compartment with a special assembly also provided by Traxxas. The magnet which attached to the inner gear generates a pulse each rotation. The sensor works on the hall effect principle where it provides a current across its terminal when placed in a magnet's field. The RPM sensor has three pins namely Vcc, Signal, and GND.

- Battery Voltage Divider Circuit
- (Need Niket’s help)

=== Software Design ===

The software for the motor node was divided into multiple files and made modular to improve readability and understanding of the complex logic involved. The main code modules are for:
• Servo Motor
• Electronic Speed Controller
• RPM Sensor
• Motor Wrapper
• Battery Voltage

The motor wrapper module is used to wrap all the code from the esc, servo, and rpm modules into simple to use functions to be called in the periodic tasks.
• Servo Motor
It uses the steering value sent from the driver (-2 to 2) and matches it to the appropriate PWM value for steering. This code module is run at 10Hz.
<pre>
void servo__steer_processor(int16_t steering_value) {
switch (steering_value) {
case MOTOR_STEERING_hard_left:
servo__steer_hard_left();
break;
case MOTOR_STEERING_slight_left:
servo__steer_soft_left();
break;
case MOTOR_STEERING_straight:
servo__steer_straight();
break;
case MOTOR_STEERING_slight_right:
servo__steer_soft_right();
break;
case MOTOR_STEERING_hard_right:
servo__steer_hard_right();
break;
default:
printf("\nDid not receive steering value");
}
}
</pre>
• Electronic Speed Controller

This code module is used to control the DC motor. It receives the motor direction value from the driver and sets the appropriate PWM value. Based on the value the motor is commanded to move the car forward or backwards. A switch case is implemented to set PWM values for movement in different directions along with different speeds.
<pre>
void esc__direction_processor(int16_t direction_value) {
desired_direction_value = direction_value;
switch (direction_value) {
case MOTOR_SPEED_reverse_fast:
esc__reverse_fast();
break;
case MOTOR_SPEED_reverse_medium:
esc__reverse_medium();
break;
case MOTOR_SPEED_reverse_slow:
esc__reverse_slow();
break;
case MOTOR_SPEED_neutral:
esc__neutral();
break;
case MOTOR_SPEED_forward_slow:
esc__forward_slow();
break;
case MOTOR_SPEED_forward_medium:
esc__forward_medium();
break;
case MOTOR_SPEED_forward_fast:
esc__forward_fast();
break;

default:
printf("\nDid not receive direction and speed value");
}
}
</pre>

There is also a feedback loop to control the speed. The ESC code depends on the rpm sensor code for the current speed values.
<pre>
double current_speed = get_speed_kph();
double desired_speed = desired_speed_kph;
float adjusted_duty_cycle = 0.0;
adjusted_duty_cycle = duty_cycle + (speed_to_pwm_adjustment(desired_speed, current_speed));
</pre>

[[File:CMPE243_S20_T2_Canster_Truck_Motor1.png|thumb|center|400px| Motor Flowchart 1]]

• RPM Sensor
This code module is used to get current speed data from the RPM sensor. It is based on interrupts. When the wheel rotates once, we get one pulse due to the magnet installed. This pulse generates a falling edge interrupt during which we increment the pulse counter. Since, this code is run at 1Hz we collect the number of pulses generated every one second. This gives us the number of rotations per second using which we can calculate the speed in kph.
<pre>
float rpm__calculate_speed_kph() {
uint16_t rotation_per_sec = pulse_count;
pulse_count = 0;
speed_kph = ((CIRCUMFERENCE_METER * rotation_per_sec) * (MPS_TO_KPH_CONVERSION_FACTOR)) / GEAR_RATIO;
return speed_kph;
}
</pre>

• Motor Wrapper
As mentioned above, the main function of this code module is to wrap all the other code modules and call the right functions at the appropriate frequency. The motor wrapper code also includes a state machine for ensuring a smooth transition between forward to backward state and vice versa. In order to achieve a smooth transition, a series of PWM pulses must be generated at the right time. For example, when the motor is moving from forward to backward state, a reverse value must be given first followed by at least three neutral values, and then continue with reverse values.

[[File:CMPE243_S20_T2_Canster_Truck_Motor2.png|thumb|center|400px| Motor Flowchart 2]]

=====LIPO Battery Voltage=====
The LIPO Battery Voltage was calculated using ADC in Burst Mode. A LIPO Hardware module was created for the same which contained two functions, <code>lipo__init</code> and <code>lipo__get_voltage</code>.

The voltage divider circuit is stepped down from 7.4V to 2.1V using 10K and 4K Resistor pair.

'''LIPO Initialization'''

The LIPO Initialization phase initializes the ADC, Enables Burst mode on the ADC pins and configures the Alternate Function Registers for the same.

'''LIPO Get Voltage'''

We read the raw ADC value from the LPC Hardware register. This value will be from 0 - 3.3V. However due to our voltage divider configuration the max voltage that we should theoretically get is 2.1V. This means that 2.1V corresponds to 7.4V of the LIPO Battery voltage.

The formula used is
<code>(raw_adc_value * MAX_LIPO_BATTERY_VOLTAGE_VALUE) / MAX_LIPO_ADC_VALUE</code>

=== Technical Challenges ===
<ol>
<li>Changing movements of the car from Forward to Backward and vice versa
If you just change the PWM value from say 16 (Forward) to 14(Backward), the DC motor will just stop and will not make wheels turn reverse. We discovered this problem quite late as during the initial testing we had always run the car from the start with either forward or reverse but never tried changing the direction during run-time.
Solution: The motor requires a series of PWM pulses which is specific to the car to transition from forward mode to reverse mode. In our case we had to give the PWM pulses in the following sequence. Suppose,
<ol>
<li> Forward (16) (callback_count=0)</li>
<li> Forward (16) (callback_count =1)</li>
<li> Reverse (14) (callback_count =2)</li>
<li> Neutral (15) (callback_count = 3)</li>
<li> Neutral (15) (callback_count = 4)</li>
<li> Neutral (15) (callback_count = 5)</li>
<li> Reverse (14) (callback_count = 6)</li>
<li> Continue reverse</li>
</ol>
Similarly, the reverse to forward can also be implemented.
<li>DC motor shooting off when there is an improper ground connection
When we connected the battery voltage circuit for reading the voltage from the battery, the motor would randomly shoot off every now and then.
Solution: Connect the voltage divider circuit to the common ground rather than taking the ground from the ESC.</li>
</ol>

<HR>
 

== '''Geological Controller''' ==

<Picture and link to Gitlab>

===Messages===
*GEO_HEARTBEAT: Used to check for MIA by other nodes. Highest priority message for GEO Node

*GEO_DEGREE: Sends the current degree relative to the North Pole computed by the Compass and the Required degree relative to the North Pole computed by Bearing Angle using the Current Coordinate and Destination Coordinate.

*GEO_DESTINATION_REACHED: Sets a flag, 0 for destination not reached and 1 for destination reached

*GEO_CURRENT_COORDINATES: Debug Message used to send the Current GPS Coordinates

*GEO_DISTANCE_FROM_DESTINATION: Debug message used to send the Distance from Destination

*CURRENT_CHECKPOINT_DBG: Debug message used to check which checkpoint is being navigated to

=== Hardware Design ===

[[File:CMPE243_S20_T2_GEO1.png|thumb|center|650px| Geological Diagram]]

=== Software Design ===
=====Overview=====
*Inside the `periodic_callback__initialize`
**Initialize the CAN BUS
**Initialize the GPS

*Inside the `periodic_callback__1hz`
**Handle all MIA (from other Nodes)
**Update GPS LED when init and in case of failure
**Compute the GEOLOGIC for Waypoints algorithm once every second (1000 ms)

*Inside the `periodic_callback__10hz`
**Handle CAN Incoming messages (Decode)
**Transmit CAN Geo messages (Encode and send)
**Compute the GPS Coordinate

=====Compass I2C Driver=====
An online datasheet resource was used to work with the Compass (https://www.robot-electronics.co.uk/htm/cmps11i2c.htm)
Initially the Compass I2C Driver was tested using the Terminal I2C Helper built by our Professor Preetpal Kang. Using this resource we were quickly able to read various I2C Registers and display it onto the terminal.

For our project the only required part of the Compass was the 16-bit Compass Bearing value (0-3599) i.e 0-359.9 degree values. These values were stored in the 2nd and 3rd register (Register 2 being the High Byte).
Once the raw data was received over I2C we could easily combine the data

<pre>
uint16_t bearing_value = (Reg2 << 8) | Reg3;
float rval = bearing_value / 10.0;
return rval;
</pre>
The returned value were transmitted to the Driver Node to compute its steering based on the required Bearing Angle.

=====GPS Initialization=====
GPS Initialization activates the Hardware GPIO (RX and TX), FreeRTOS Queue for UART Interrupts (UART Module) and Line Buffer Module to parse each GPS line.

=====GPS Data Parsing=====
The GPS Hardware module transmits an NMEA string over UART to the SJTwo Board. We read each character one by one and add it to the Line Buffer module.
Inside its computation loop, the Line Buffer module checks if a newline character has been received.
When a newline character has been received the entire string is extracted from the line buffer module and parsed according to its identifier ($GPRMC, $GPGGA) received and parsed into individual tokens.
For our purposes the $GPRMC NMEA string was the most appropriate and it helped us extract the Current Latitude Longitude as well as the Valid/Invalid tag for the Canster Truck.

=====GPS LED Indication for debugging=====

A simple module that checks for the GPRMC GPS Message and extracts the A or V valid (Tag). If $GPRMC NMEA string is valid, LED is set, else LED is reset. This gives us onsite debugging capabilities to know if GPS has locked onto a satellite signal.

=====GEO Logic Module Computation=====
The GEO Logic Module computes the Bearing Angle, Haversine Distance as well as the Waypoints algorithm.

'''Bearing Angle:'''

<code>
θ = atan2( sin Δλ ⋅ cos φ2 , cos φ1 ⋅ sin φ2 − sin φ1 ⋅ cos φ2 ⋅ cos Δλ )
</code>

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

Since atan2 returns values in the range -π ... +π (that is, -180° ... +180°), to normalize the result to a compass bearing (in the range 0° ... 360°, with −ve values transformed into the range 180° ... 360°), convert to degrees and then use (θ+360) % 360, where % is (floating point) modulo.
For final bearing, simply take the initial bearing from the endpoint to the start point and reverse it (using θ = (θ+180) % 360).

The above article reference gives us the required bearing angle that our car must align itself to, to reach a particular destination coordinate from its current coordinate.
The Steering of the Canster Truck depends on the above-computed angle values.

'''Haversine Distance Formula:'''

This uses the ‘haversine’ formula to calculate the great-circle distance between two points – that is, the shortest distance over the earth’s surface – giving an ‘as-the-crow-flies’ distance between the points (ignoring any hills they fly over, of course!).

<code>
a = sin²(Δφ/2) + cos φ1 ⋅ cos φ2 ⋅ sin²(Δλ/2)

c = 2 ⋅ atan2( √a, √(1−a) )

d = R ⋅ c
</code>

where φ is latitude, λ is longitude, R is earth’s radius (mean radius = 6,371km);
note that angles need to be in radians to pass to trig functions!

The above formula is used to calculate the distance between the source coordinate (received via GPS) and the destination coordinate.
Later this was used to compute the distance between source coordinate and each individual checkpoint to traverse the shortest distance.

'''Waypoints Algorithm:'''

The Waypoints algorithm that was chosen was a slightly modified version of Djikstra’s Algorithm.
3 values were calculated before the final computation

- Distance between source and final destination (DISTsd)

- Distance between source and each individual checkpoint (DISTsc)

- Distance between each individual checkpoint and the final destination. (DISTcd)

If DISTsd was lesser than DISTcd, this checkpoint was discarded (we continue in the loop). Since we would be moving in the opposite direction, rather than towards the final destination.

If DISTsd was greater than DISTcd, then we checked the nearest checkpoint to the source.
The minimum value was set initial that was equal to DISTsd.

If DISTsc was lesser than the minimum value stored, DISTsc would become the new minimum value, and the checkpoint index and coordinates would be appropriately stored and returned from the function.

In this way we would navigate to the nearest checkpoint from the source, while also making sure NOT to travel in the opposite direction.
This logic is recomputed only when we reach the checkpoint selected and the algorithm runs again to find the next checkpoint that we need to navigate to.

=====CAN Decode Destination Coordinates=====
Destination Coordinates are received from the Bridge and Sensor Node and transmitted over the CAN Bus. The value is decoded and stored in the GEO Logic Module.
This is a very important value since our entire GEO Logic calculations are based on the Destination Coordinate.

=====CAN Encode and Send=====

The main messages that were transmitter are
#Geo Degree
#Geo Destination Reached
#Distance from Destination Debug and Checkpoint Index debug

'''Geo Degree Computation as per Waypoints Algorithm:'''

Geo Degree was computed as per the current coordinates and the most recently computed checkpoint coordinates. This bearing angle calculation w.r.t computed checkpoint would continue till we do not reach that particular checkpoint.
Once we reach the computed checkpoint, Waypoint algorithm is recomputed as per the process mentioned above and the algorithm runs again.

'''Geo Destination Reached:'''

An Area of around 4 meters was set around the destination coordinate to check if the destination had been reached.
This measurement was taken into consideration to allow for the loss in precision when transmitting data over CAN as well as any irregularities that might occur when getting values from the GPS.
Having an area of 4 meters was very accurate for all of our test runs.

'''Geo Distance from Destination Debug and Checkpoint Index Debug:'''

Getting debug information was very critical to speed up our development process. In this case we could actively see if our algorithm worked properly.
The Geo Distance from Destination was used to see if we were moving closer to our destination or veering further away from it.
The Checkpoint Index was used to see which checkpoint index we were traveling to. By knowing the placements of the Individual checkpoints we could manually as well as programmatically (via Android application) verify the working of our Canster Truck.

=== Technical Challenges ===
#DBC Challenge for GEO Coordinates -> Could not encode more than 5-6 decimal places at a time, on later investigation we found that the 10000 is an int value, however 100000 overflows the int value.
#Creating an efficient algorithm for Waypoints, O(n) complexity.
#Getting appropriate fixes for GPS when not in a completely open space.
#GPS used to fluctuate or stop giving values when Battery voltage went below a particular threshold. Always supply 3.3V constantly at a good amperage.

<HR>
 

== '''Sensor [Bridge and Sensor Controller]''' ==
<Picture and link to Gitlab>

==='''Ultrasonic Sensor'''===
====Hardware Design====
This sensor uses an ultrasonic beam to measure the distances. Based on the time taken between when the beam is sent and received back to the sensor, the distance is calculated in the node.
Apart from 5v and GND, this sensor has 2 pins ECHO and TRIG which are interfaced with the SJ-Two board via GPIO.

[[File:CMPE243_S20_T2_CansterTruck_ultrasonic_sensor.jpg|thumb|center|300px| Ultrasonic Sensor Diagram]]

====Software Design====
* Init the GPIO pin connected to TRIG of the sensor as output and for ECHO as an input port.
* Attach the interrupt on the ECHO input port.
* Store the system_clock_count before setting the trigger pulse and then set the pulse. Also keep monitoring the input port.
* Take the system_clock_count at the instant of receiving the interrupt.
Distance = (system_clock_count_at_trig - system_clock_count_after_at_echo) / 57.14

==='''Lidar Sensor'''===
====Hardware Design====
The RPLidar sensor can be powered from a 5-volt source and uses UART communication to receive commands and transmit data. It has seven pins to interface with. Two sets of the pins (four total) are for power and ground. The remaining three are for UART receive and transmit, and for making the lidar’s motor spin.

[[File:CMPE243_S20_T2_Canster_Truck_RPLidar_A1.JPG|thumb|center|300px| RPLidar A1]]

====Software Design====
In terms of the lidar, the SJ2 initializes GPIO, UART, and memory for storing the measurement values. After initialization, the command to begin scanning is sent. Here, we wait for the lidar to send a response packet, letting the host (SJ2 board) know it received the command. The response packet the lidar sends will be 7 bytes. If the correct 7 bytes are not received, the command will be sent again.

[[File:CMPE243_S20_T2_Canster Truck_Lidar_flow.jpeg|thumb|center|200px| Lidar Flow]]

Following the response packet, the lidar begins sending 5-byte measurement data. Each sample contains a distance measurement (in millimeters) and the angle (with respect to the lidar) in which it was taken. The data packet structure is shown in the following figure. In addition to containing the distance and angle, the packet includes a quality value, to indicate the reliability of the measurement, and three check bits (S, ~S, and C). As the data is received via UART, we wait until we have 5 bytes before continuing to process. Before processing the 5 bytes after receiving them, the check bits are confirmed to be correct. If they are incorrect, it will not be processed and we will wait for another sample to be received.

[[File:CMPE243_S20_T2_Canster Truck_DataPacketStructure.JPG|thumb|center|200px| Data Packet Structure]]

In the case the sample is correct, each measurement value that is in a direction of interest will be placed in an array designated to one of four directions (left, right, front, rear). Each of these directions have their own sector in the lidar’s 360-degree view.
*Right sector: 11°-30°
*Rear sector: 170°-190°
*Left sector: 330°-349°
*Front sector: 350°-370° (or 10°)

The arrays mentioned will hold roughly 20 measurements, which are every degree in the sector. In the event, objects are too far to measure, the lidar will report 0 mm. distance. Since there is no measurable obstacle, a “large” distance value of 3000 mm. is placed in the array. The smallest distance value will be taken from each array and reported to the driver node for obstacle avoidance.

=== Technical Challenges ===
====Ultrasonic====
====Lidar====
*'''Datasheet not 100% clear:''' The correct datasheet for the was a bit difficult to obtain, and the manufacturer needed to be contacted. The first document found online was high level and general information about the sensor, but the manufacturer did provide another document that contained the information of the commands and responses to and from the lidar, and their packet structure. The documents did not clearly state the angles with respect to the lidar are fixed, which left me wondering if the lidar will think the direction it is facing when powered on will become the new “zeroth” angle.

*'''UART Buffer Overflow:''' When first interfacing with the sensor, the incoming bytes of the lidar were printed on to the terminal to make sure there was a response and to make sense of the information. Since the command we sent results in 5 bytes of data per measurement samples from the lidar and the lidar measured 2000 times per second, there are will be roughly 10k Bytes per second of data incoming that need to be handled continuously. With an improperly sized UART buffer and print statements it is guaranteed to occur, making the lidar data look like random values.

*'''Proper Parsing of Measurement Data:''' After sending a command to the lidar, the sensor will send a response packet, followed by the measurement data. The initial response from the lidar is a 7-byte packet, followed by continuous 5-byte measurement samples. I needed to make sure however I handled the response would be independent of how the measurement is handled, so as not to create a potential unwanted offset when receiving measurements.

*'''Object Detection with Received Data:''' Once proper communication was set up with the lidar and measurement data was getting decoded, there needed to be a way to measure when obstacles were present. If ~360 measurements are handled entirely independently from one another, it could become a complex and confusing code. To achieve a simple approach, four sectors about 20 degrees in size were used to represent the front, left, right, and rear directions.

*'''Bugs in Code:''' When first implementing the code, there were a few bugs from typos, incorrect numbers, and some faulty logic that were found with the use of unit testing. Unit testing helped find these issues and verified the logic was correct, and I would say gave me 90% confidence in my lidar handling.

<HR>
 

== '''Bridge [Bridge and Sensor Controller]'''==
<Picture and link to Gitlab>

Bridge functionality of the Bridge and Sensor Controller is to establish wireless communication between the SJ-2 Board and the android mobile device using the HC-05 Bluetooth module. The Bridge controller will be receiving start command with destination GEO coordinates and stop command. The Bridge controller will be transmitting the required sensor data and debug information to be displayed on the android application.

[[File:CMPE243_S20_T2_BRIDGE.png|thumb|center|500px| Bridge Diagram]]

===Bluetooth===

==== Software Design ====

'''Low-Level Layer'''

In this layer, similar to the GPS the UART GPIO was initialized (RX, TX), FreeRTOS Queue was initialized for UART Interrupts and the line buffer module was initialized to parse strings.

Two basic functions <code>bt__read</code> and <code>bt__write</code> were implemented.
As the name suggested, <code>bt__write</code> took a string as its input parameter and transmitted that data to the Android application. <code>bt__read</code> stored the incoming characters into the line buffer, parsed the line received into its identifier and tokens, and invoked a callback function.

Since this was a low-level layer the User would not be directly invoking this library. Instead a '''Bluetooth Wrapper''' module was created which would be invoked and used by the user.

'''Application Layer'''

The Bluetooth Wrapper module had the appropriate <code>read_once</code> and <code>write_once</code> functions.

The <code>read_once</code> function internally just called the <code>bt__read</code> function. All of the decodings was done inside the Callback Function.
To get the Destination coordinate the string received from the Android Application was in the form of
<code>$loc,<destination_latitude>,<destination_longitude>.</code>
Upon receiving this data we parsed the destination_latitude and destination_longitude, which could later be accessed using getters.
We also set a start flag to notify the Driver Node that destination has been received and we can start steering towards our checkpoints.

Another command implemented was the stop command.
<code>$stop</code>
This was used to send a stop flag to the Driver node.

The <code>write_once</code> function used the getter methods from each CAN Decode message and update its internal state variables. A CSV String was created using the <code>$canster</code> identifier and various debugging points were appended to this message using a comma.
On the Android application side this CSV string was tokenized and displayed onto the Application Debug screen appropriately.

==== Technical Challenges ====

<List of problems and their detailed resolutions>

<HR>
 

== '''Driver [Driver and LCD Controller]''' ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===

[[File:CMPE243_S20_T2_Canster Truck_Driver_Flowchart.png|thumb|center|750px|Driver Flowchart]]

The above block diagram explains the process flow of obstacle detection for the car. The LIDAR detects
the obstacle and depending on the distance of obstacle the car takes a slight right and slight left or a
hard right and hard left. The state of the car also depends on the value of the LIDAR and ultrasonic sensor.
The loose ends of the LIDAR for the reverse condition are checked by the ultrasonic sensors. The
The ultrasonic sensor works on the principle of trigger and echo and can detect the obstacles very close by.
The range of the Ultrasonic sensor is lower than the LIDAR. Finally, if no obstacle is detected the car goes
straight until the destination is reached. The speed of the car is also various when an obstacle is detected to
avoid the crash and the car’s smooth transition from one state to another. The key to the android
application controls the start and stop the process of the car. If the key is not pressed, then the stays in the

neutral state. The speed of the car is controlled by the changing duty cycle of the input voltage. There
are seven-speed levels in which the motor can run on. These speed levels are Forward Slow, Medium,
Fast, Reverse Slow, Medium, Fast, and Neutral. The Neutral is the stop condition with a 0% duty cycle.

=== Technical Challenges ===

< List of problems and their detailed resolutions>

<HR>
 

== '''LCD [Driver and LCD Controller]''' ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
The GLCD used was created by 4DSystems, using their IDE a UI was created. Each UI component could be controlled by sending UART data targeted at the widget address.
The best part about this GLCD was that we had a lot of interactive widgets to display debugging information in real-time.
The GLCD code was divided into 3 parts:
<ol>
<li>'''Low-Level Initialization'''
Initialize the low-level hardware interfaces to send and receive data from the GLCD.
Similar to the GPS and Bluetooth, The UART GPIO was initialized (RX, TX), FreeRTOS Queue was initialized for UART Interrupt and line buffer was used to get a stream of data for parsing.

Low-level '''read''' and '''write''' commands were used as per the working of the GLCD Module.
When Reading data pertaining to a widget on the GLCD we would need to send a particular response packet.
<pre>
void lcd__read(lcd_object_e object_id, uint8_t object_index, uint8_t *response, uint16_t *response_data) {

uint8_t checksum = READ_OBJ ^ object_id ^ object_index;
uint8_t buffer[] = {READ_OBJ, object_id, object_index, checksum};

lcd__write_data(buffer, sizeof(buffer) / sizeof(uint8_t));
lcd__read_response_id(response);
lcd__read_response_data(response_data);
}
</pre>

The response_data returned contains the Widget ID as well as the current value stored on that widget.

When Writing data pertaining to a widget on a GLCD the process is similar to the above mentioned code.
<pre>
void lcd__write(lcd_object_e object_id, uint8_t object_index, uint8_t msb, uint8_t lsb, uint8_t *response) {
uint8_t checksum = WRITE_OBJ ^ object_id ^ object_index ^ msb ^ lsb;
uint8_t buffer[] = {WRITE_OBJ, object_id, object_index, msb, lsb, checksum};

lcd__write_data(buffer, sizeof(buffer) / sizeof(uint8_t));
lcd__read_response_id(response);
}
</pre>

However in this case we receive only an ACK or NACK from the system. ACK would mean that the write to GLCD widget was successful and the widget now stored appropriate values. NACK would mean that a particular error has occurred. The errors could be regarding baud rate, incorrect bit format, incorrect index values, etc.
</li>
<li>'''GLCD Wrapper for Widgets'''
The above low-level code had generic read and write functions. However for our UI we were only using 3 Widgets. All of which had '''different Indexes''' and '''Widget IDs'''.
Therefore a very simple library was created to easily interface with those widgets
<pre>
bool lcd_wrapper__read_led(uint8_t index);
uint16_t lcd_wrapper__read_meter(uint8_t index);
uint16_t lcd_wrapper__read_leddigit(uint8_t index);

bool lcd_wrapper__write_led(uint8_t index, bool value);
bool lcd_wrapper__write_meter(uint8_t index, uint16_t value);
bool lcd_wrapper__write_leddigit(uint8_t index, uint16_t value);
</pre>

The above code is self-explanatory read and write functions for '''LED''', '''METER''', and '''LED DIGIT'''.
</li>
<li>'''GLCD UI'''
Now that we had our low level and Widget wrapper working properly, we wanted to create our Dynamic UI as well. The code would need to be robust enough to handle any UI that we create on the GLCD which could be reflected equivalently in our C Code.

<pre>
static void lcd_ui__update_ui(void) {

lcd_wrapper__write_led(LCD_LED_DRIVER_MIA_INDEX, driver_mia_led);
lcd_wrapper__write_led(LCD_LED_SENSOR_MIA_INDEX, sensor_mia_led);
lcd_wrapper__write_led(LCD_LED_GEO_MIA_INDEX, geo_mia_led);
lcd_wrapper__write_led(LCD_LED_MOTOR_MIA_INDEX, motor_mia_led);

// kph is always in the range of 0 - 10
lcd_wrapper__write_meter(LCD_METER_KPH_INDEX, kph_meter % 11);

// These will be in the Range of 0-99
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_RPM_INDEX, rpm_leddigit % 100);
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_CURRENTDEGREE_INDEX, cdegree_leddigit % 100);
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_REQUIREDDEGREE_INDEX, rdegree_leddigit % 100);
}
</pre>

As we can see the `lcd_ui__update_ui` function was called periodically inside the 1Hz function. It updated the screen in real time based on the static values that were stored AND updated inside the LCD UI module.
The Constant INDEX values stored were directly mapped onto the Index values were received from the 4DWorkshop UI Software.
</li>
</ol>

=== Technical Challenges ===

< List of problems and their detailed resolutions>

<HR>
 

== '''Android Application''' ==
[https://gitlab.com/akhilcherukuri/can-ster_truck_application Gitlab]
=== Software Design ===

<div><ul>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android1.jpg|thumb|none|250px|Splash Screen]]</li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android2.jpg|thumb|none|250px|Main Activity Screen]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android3.jpg|thumb|none|250px|Map Activity Screen]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android4.jpg|thumb|none|250px|Info Activity Screen 1]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android5.jpg|thumb|none|250px|Info Activity Screen 1]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android6.jpg |thumb|none|250px|Debug Activity Screen]]</li>
</ul></div>

The application consists of a total of 5 Activities:

*'''Main Activity:'''
**This is the app launch display screen
**It will check for all the required permission onStart().
**Has search button for connecting from a paired device list view
**Once device is clicked, an intent will start the Map Activity
*'''Map Activity:'''
** For this requirement we are using the Google Maps Fragment, for the map fragment to function we must request an API key from Google and set the key in the manifest of the application.
** Destination marker(Red Marker) is set using setOnMapClickListener to which the car will navigate to, the destination can be changed by clicking elsewhere on the Map Fragment. The marker can be removed using setOnMarkerClickListener.
** When the start button is pressed, the start command identifier along with destination latitude and longitude is sent to the car via the write thread. A background thread is started along with it to indicate the current car's position(Green Marker) along with a plotline between the current position and destination.
** When the stop button is pressed, the stop command identifier is sent to the car, to stop and turn off the car.
*'''Info Activity:'''
** Messages from Geological, Driver, Motor coming from CAN bus are decoded by the Sensor and Bridge controller and sent to the Android application as a string.
** The received string is parsed and categorizes the data to store it in the required textView to be displayed.
** Bluetooth status, Lidar Values, Ultrasonic Sensor Values, Motor Speed, Motor RPM, Motor PWM, Cars' current location, Compass Heading, Distance till Destination, Checkpoint Index is displayed. This was useful for debugging purposes and allowed us to avoid scanning the mounted LCD or CAN Busmaster on PC during drives.
*'''Debug Activity:'''
**The main function of this activity is to check all RAW RX and RAW TX messages and create a log of all the data received and sent.
*'''Bluetooth Connection Service Activity''' :
**This is the background activity that handles all the threads required for transmission and receiving data using Bluetooth connections. It has 3 running threads which is called inside other activities using a handler:
** Accept Thread - Listens to BluetoothServerSocket using listenUsingRfcommWithServiceRecord. In order for the RF communication socket to connect to the HC-05, we used the following UUID: 00001101-0000-1000-8000-00805F9B34FB. This is a generic SSP Bluetooth UUID that enables the socket to directly connected to HC-05 and maintain the connection.
** Connect Thread - Creates a Bluetooth socket using createRfcommSocketToServiceRecord
** Connected Thread - Creates socket.getInputStream(); and socket.getOutputStream(); when bytes are available in input stream it will read them into a buffer.
***All messages for activities are done by Handler mHandler.obtainMessage(); mHandler.sendMessage();

*'''Receieved string''':
** A String is sent to the Bluetooth app from HC-05 and when it receives a string with identifier "$canster", the message is prased accordingly by using the string delimiter ',' and is ended by the newline character '\n' which will remove the data from StringBuffer.
** Example: $canster,37.339334,-121.881123,37.338713,-121.880685,10.123,20.133,30.123,10.5,88.1,99.2,-2,1,44,7,11,22,33,-3,23\n

[[File:CMPE243_S20_T2_BLUETOOTHFLOWCHART.png|thumb|center|650px| Android Application Flowchart]]

=== Technical Challenges ===

<HR>
 

== '''Mangaement''' ==
===Team Management ===
===Git Management===

Git Management amongst 6 team members was definitely a very challenging task. Depending on our initial design we could’ve had a lot of merge conflicts. However those risks were mitigated by spending a LOT of time in the initial stages to decide our pipeline and structure.

<li>There are certain components in our system that were COMMON. For example the CAN initialization, communication and decodes were all similar for the most part between all the 4 Controllers. The utility modules used were also similar in nature</li>
<li>Thus we made a common branch that contained the templates for CAN Nodes (not Controllers), Hardware code and Utility functions.
<ol>
<li>Later this common branch was forked into an individual Controller specific branch (SENSOR, GEO, MOTOR or DRIVER).</li>
<li>Only the Logic folder contained Controller specific code, specific to that controller.</li>
</ol>
<li>This gave us a lot of flexibility since all the team members had similar APIs to work with on all 4 branches. This promoted easy understanding and learning.
<ol>
<li>Many team members frequently worked on 2 or more controllers at a time where can messages were concerned. Having a APIs also meant that just the can_handler needed to be updated regularly followed by the equivalent logic code. </li>
<li>Inside the logic folder, getters to the can node modules were frequently used.</li></ol>
<pre>
├───can_module
│ ├───can_bus_initializer
│ ├───can_constants
│ ├───can_driver_node
│ ├───can_geo_node
│ ├───can_handler
│ ├───can_motor_node
│ ├───can_sensor_node
│ └───test
├───hardware
│ ├───bt
│ ├───compass
│ ├───gps
│ ├───lcd
│ ├───test
│ └───ultrasonic
├───logic
│ ├───driver_obstacle
│ ├───driver_state
│ ├───geo_logic
│ └───test
├───periodics
│ └───test
└───utility
├───line_buffer
└───test
</pre>

'''Challenges'''
<li>It was initially a bit of a learning curve to understand the flow of the repository</li>
<li>When using a git management system with different versions in each branch it became very tough when the number of branches suddenly exploded in size. A lot of relevant code was stuck in a lot of different branches.
<ol>
<li>This happened mainly due to assignment submissions and unclosed MRs that eventually became stale.</li>
<li>Our strategy was to abandon these MRs and keep forking from these branches without merging it back into its final controller branch.</li>
<li>The latest branches that were kept were aptly named `<controller>_bleeding_edge_dev` branches since they were never merged back from where they were forked.</li>
</ol>
<li>Since a lot of our code also depended on the DBC autogenerated code, we could not suddenly change the DBC Message names once they were established since it caused a change in the Struct name that was generated and used.
<ol>
<li>Our solution to this was to keep everything backward compatible. We added new function names without deleting old DBC messages.</li>
<li>In certain places where we wanted to modify a function name it was done one by one so that a lot of the code is not broken at one time.</li>
</ol>
<li>Common Branches eventually became stale as our progress continued on the bleeding edge branches
<ol>
<li>For example certain GPS features needed to be added which were done on the GEO_bleeding_edge_dev branch but never pushed or cherry-picked back into the COMMON branch.</li>
<li>This was a similar issue to our 2nd point but manageable since the goal of the COMMON branch was to provide a template for further work and nothing more.</li>
<li>At the end of the day each controller is its own Individual Project and while the messages between them are same. The Hardware code does not need to be same.</li>
<li>This also prompted team-members to ask if we could delete unused hardware or logic file code (which wasn’t being used and was imported from the template). This was also fine and can be done during cleanup stage. However we eventually got used to the Modular system of our project so much so that we did not worry about the additional modules that were present in each branched controller project.</li>
</ol>

<HR>
 

== '''Conclusion''' ==
CMPE243 gives one of the best experiences one could ever get in their academic life. The course is designed to give an insight into how the industry functions and enhances both technical and management skills. Apart from learning how to work and implement application of CAN protocol, one can get a hands-on experience with version control, unit-testing and software design. Overall it was a very great journey.

=== Project Video ===

=== Project Source Code ===

=== Advise for Future Students ===
'''GENERAL:'''
* Form your team and start the project as early as you can.
* Clearly discuss what role each individual should do and ensure that progress is regularly tracked so that the team doesn't fall back on any schedule.
* Since lot of code and hardware integration is involved with this project, make sure testing is thoroughly and periodically done and make note of all the issues found.
'''HARDWARE:'''
* Decide on how you would power up the peripherals. We had issues with Bluetooth (not connecting), GPS (lock not happening) and LIDAR (giving incorrect values). After lot of cycles of hardware and software debugging, we found that the issue was with power. Choose wisely as to which peripherals must be connected to which power bank.
* PCB design is time consuming as there is a lot of hardware components involved and a huge responsibility falls on the designer to know the about each component. Coordinating with multiple team members and verifying with them if their respective hardware is correct takes a lot of time. So start well ahead.
* Make sure to expose some extra GPIO and GND pins for future use.
'''MOTOR:'''
*You can use the LiPo battery to power the RPM and servo motor instead of using a separate power source. Use Vout from the ESC to get 6V.
*Start the PID control calibration early on as you will need to do extensive testing to get it working.

=== Acknowledgement ===
<HR>
Firstly we would like to express our gratitude to Professor Preetpal Kang for his guidance throughout the semester and providing us with this opportunity. We would also like to thank the ISA members Vignesh Kumar Venkateshwar and Aakash Vrajlal Chitroda for being available whenever in need and guiding us to complete the project.

== '''References''' ==

===Motor Controller===
===Geological Controller===
* Movable Scripts: [https://www.movable-type.co.uk/scripts/latlong.html Calculate distance, bearing and more between Latitude/Longitude points]
* CMPS11:[https://www.robot-electronics.co.uk/htm/cmps11i2c.htm I2C Configuration]

===Bridge and Sensor Controller===
===Driver and LCD Controller===
*LCD Software: [https://4dsystems.com.au/ulcd-32ptu 4Dsystems]
===Android===
*Youtube Channel: [https://www.youtube.com/channel/UCoNZZLhPuuRteu02rh7bzsw Coding with Mitch]
*Android Developers: [https://developer.android.com/guide/topics/connectivity/bluetooth Website][https://github.com/googlearchive/android-BluetoothChat Github]
*Udemy Course: [https://www.udemy.com/course/the-complete-android-oreo-developer-course/ Complete Android Oreo Developer Course]
===PCB Design===
*EDC Tool: [https://easyeda.com/ EasyEDA]

S20: Canster Truck

2020-05-22T05:44:35Z

Proj user22: /* Software Design */

[[File:CMPE243_S20_T2_Canster_Truck_Logo.png|thumb|455px|caption|right|CAN-STER TRUCK LOGO]]

== '''Abstract''' ==
'''The Canster Truck Project is an autonomous RC car with CAN Bus interfaced controllers. The development of the RC car's subsystem modules (Interfacing of Ultrasonic Sensor, LIDAR, Bluetooth, GPS, Compass and CAN modules) was divided among six team members. The aim of the project is to develop an autonomous RC Car which can navigate from one source location to the selected destination on the app by avoiding obstacles in its path using sensors. Waypoints algorithm is used as the path finding technique.'''

 

== '''Introduction and Objectives''' ==

'''The project was divided into 7 modules:'''

* '''Bridge and Sensor Controller'''
* '''Motor Controller'''
* '''Geological Controller'''
* '''Driver and LCD Controller'''
* '''Hardware Integration'''
* '''Android Application'''
* '''Testing & Code Review'''

'''RC Car Objectives'''
'''1. Driver and LCD Controller''' - Handles algorithms for obstacle avoidance, route maneuvering, and waypoints
'''2. Geological Controller''' - Recieves coordinates from GPS and Heading from Compass for navigation
'''3. Motor Controller''' - Controls movements of the RC Car
'''4. Bridge and Sensor Controller''' - Detects surrounding objects and interfaces android application to controller via bluetooth
'''Team Objectives'''

[[File:CMPE243_S20_T2_High_Level_System_Diagram.png|thumb|center|800px| High Level System Diagram]]

 

== '''Team Members and Responsibilities''' ==

'''Gitlab Project Link''' - [https://gitlab.com/coder137/can-ster_truck '''Canster Truck''']
 

*'''Niket Naidu''' [https://www.linkedin.com/in/niket-naidu-30090a134/ LinkedIn] [https://gitlab.com/coder137 Gitlab]
** '''Geological Controller''' : Waypoint Algorithm, Haversine and Bearing Angle logic
** '''Driver and LCD Controller''' : GLCD
** '''Bridge and Sensor Controller''' : Bluetooth
** '''Testing & Code Review'''

*'''Ganesh Ram Pamadi''' [https://www.linkedin.com/in/ganeshram93/ LinkedIn] [https://gitlab.com/ganeshram2493 Gitlab]
** '''Hardware Integration'''
** '''Testing & Code Review'''
** '''Driver Controller'''
** '''Motor Controller'''

*'''Nikhil Pabbisetty''' [https://www.linkedin.com/in/nikhilpabbisetty/ LinkedIn] [https://gitlab.com/nikhilpeoria Gitlab]
** '''Bridge and Sensor Controller'''
** '''Motor Controller'''

*'''Akhil Cherukuri''' [https://www.linkedin.com/in/akhilcherukuri/ LinkedIn] [https://gitlab.com/akhilcherukuri Gitlab] [https://github.com/akhilcherukuri Github]
** '''Android Application'''
** '''Bridge and Sensor Controller'''

*'''Ashish Anant Ladage''' [https://www.linkedin.com/in/ashish-anant-ladage-7bb3a214b/ LinkedIn] [https://gitlab.com/ashishladage1 Gitlab]
** '''Driver and LCD Controller'''
** '''Hardware Integration'''
** '''Motor Controller'''

*'''Jesus De Haro De Reza''' [https://www.linkedin.com/in/jesus-de-haro-66342424/ LinkedIn] [https://gitlab.com/deharo27 Gitlab]
** '''Bridge and Sensor Controller'''
** '''Motor Controller'''

 

== '''Administrative Responsibilities''' ==
* '''Team Lead''' - [https://www.linkedin.com/in/niket-naidu-30090a134/ '''Niket Naidu''']
* '''Git Repository Manager''' - [https://www.linkedin.com/in/niket-naidu-30090a134/ '''Niket Naidu''']
* '''Bill Of Materials Manager''' - [https://www.linkedin.com/in/akhilcherukuri '''Akhil Cherukuri''']
* '''Wiki Report Manager''' - [https://www.linkedin.com/in/akhilcherukuri '''Akhil Cherukuri''']

 

== '''Schedule''' ==

{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-

! scope="row"| '''1'''
| style="text-align:center;" |'''02/11/2020'''
| style="text-align:center;" |'''02/17/2020'''
|
*'''Form teams and decide group name'''
*'''Review past projects'''
*'''Slack: Create project group and invite Preet'''
*'''GitLab: Create project groups repository'''
*'''Analysis of component required'''

|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''2'''
| style="text-align:center;" |'''02/18/2020'''
| style="text-align:center;" |'''02/24/2020'''
|
*'''Study CAN Communication'''
*'''Create Bill of Materials'''
*'''Order RC Car'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''3'''
| style="text-align:center;" |'''02/25/2020'''
| style="text-align:center;" |'''03/02/2020'''
|
*'''Setup team finance management using Splitwise application'''
*'''Complete Bill of Materials'''
*'''Order all other required components'''
*'''Wikipedia: Setup project report template'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''4'''
| style="text-align:center;" |'''03/03/2020'''
| style="text-align:center;" |'''03/09/2020'''
|
*'''Read the respective datasheets and manuals for each component'''
*'''Test each component for working conditions'''
|
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''5'''
| style="text-align:center;" |'''03/10/2020'''
| style="text-align:center;" |'''03/16/2020'''
|
*'''Assign team responsibilities and roles'''
*'''Setup team project management environment (ClickUp)'''
*'''Define CAN DBC'''
*'''Research GPS antennas and order'''
*'''Android: Environmental setup of Android Studio and enable version control'''
*'''Hardware : Decide PCB editing software (easyEDA)'''
*'''Hardware : Draft schematic for required PCB design'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''6'''
| style="text-align:center;" |'''03/17/2020'''
| style="text-align:center;" |'''03/23/2020'''
|
*'''Hardware : Create model of PCB''' 
*'''Android: Add a Button for changing bluetooth connection status in the application''' 
*'''Geological: Interface Compass module with SJ-2 board using I2C interface''' 
*'''Geological: Interface GPS module with SJ-2 board using the UART interface''' 
*'''Geological: Parse raw data to get meaningful values for GPS and Compass''' 
*'''Sensor: Interface and check the functionality of ultrasonic sensors to the SJ-2 board''' 
*'''Motor: Interface of Servo & DC motor to the SJ-2 board and check for basic functionality''' 
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''7'''
| style="text-align:center;" |'''03/24/2020'''
| style="text-align:center;" |'''03/30/2020'''
|
*'''Hardware : Finalize components placement on PCB.''' 
*'''Motor: Add PWM functionality and test the code on DC and servo motors''' 
*'''Sensor: Interface and check and study the output readings of Lidar sensor with SJ-2 board over UART''' 
*'''LCD Display: Explore UI designing of LCD''' 
*'''Hardware: Finalize on optimal ultrasonic sensor placements''' 
*'''Android: Initiate Bluetooth communication and show staus via text view''' 
*'''Wikipedia: Establish final wiki schedule'''
*'''Complete CAN communication format for each controller and link DBC file to the Wiki'''
*'''Complete high-level system block diagram'''
*'''Complete unit-level block diagrams'''
*'''Bridge: Interface HC-5 bluetooth module with Sj-2 board using serial communicaton'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''8'''
| style="text-align:center;" |'''03/31/2020'''
| style="text-align:center;" |'''04/06/2020'''
|
*'''Hardware: Analyze PCB model and order PCB Circuit board''' 
*'''Android: Initiate Bluetooth communication and send "Hello World".''' 
*'''Wikipedia: Start adding information/images/diagrams to the relevant sections'''
*'''Motor: Configure ESC for correct speed outcome according to frequency & PWM values''' 
*'''Motor: Finish RPM sensor hardware and software implementation and integration''' 
*'''Sensor: Read output from Lidar and setup structure for outputting for DBC''' 
*'''Geological: Implement waypoints algorithm''' 
*'''Driver: Implement obstacle avoidance algorithm''' 
*'''Bridge: Pass data such as "Hello World" from HC-05 bluetooth module to bluetooth terminal android application'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''9'''
| style="text-align:center;" |'''04/07/2020'''
| style="text-align:center;" |'''04/13/2020'''
|
*'''Hardware: Remove Unused parts from RC Car''' 
*'''Hardware: Mount PCB and 3D Parts''' 
*'''Motor: Decide different cut-off values from sensor to command right /slight right/ straight/ slight left/ left to motor.''' 
*'''Android: Embed Google Maps API for setting the car's destination.''' 
*'''LCD: Work to show RC cars live status information(battery level, current speed, long, lat, bearing, sensor data, etc)''' 
*'''Driver: Test obstacle avoidance algorithm and fine-tune sensor readings''' 
*'''Geological: Test checkpoint algorithm''' 
*'''Bridge: Establish two way communication between android application and bluetooth module''' 
*'''Update Bill of Materials for miscellaneous hardware'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''10'''
| style="text-align:center;" |'''04/14/2020'''
| style="text-align:center;" |'''04/20/2020'''
|
*'''Hardware: Integrate all hardware modules''' 
*'''LCD: Testing & Validation of the LCD UI and display vehicle status information''' 
*'''Android: Send car location to the app and checkpoints received to Geo module''' 
*'''Motor: Optimize PID control by accelerating/decelerating as instructed by Driver''' 
*'''Bridge: Configure HC-05 for auto reconnection if bluetooth communication disconnects''' 
*'''Add multiple debug messages and transmit on CAN'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''11'''
| style="text-align:center;" |'''04/21/2020'''
| style="text-align:center;" |'''04/27/2020'''
|
*'''Android: Send additional vehicle status information from RC car to the Application for display''' 
*'''Android: Finalize User Interface Design and Icon''' 
*'''Continuously test the whole system and handling of corner cases (outside).'''
*'''Finalize RC Car For Project Proto 1'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''12'''
| style="text-align:center;" |'''04/28/2020'''
| style="text-align:center;" |'''05/04/2020'''
|
*'''Gitlab: Push final code'''
*April 28th: Project Proto 1
*'''Finalize RC Car for Project Demo'''
*May 1st: Project Presentation
*'''Finalize RC Car for Project Proto 2'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''13'''
| style="text-align:center;" |'''05/05/2020'''
| style="text-align:center;" |'''05/21/2020'''
|
* '''Complete Individual Contribution Peer Grading'''
* '''Review and Complete Wiki Project Page'''
|
*'''Completed'''
*'''In Progress'''
|-
|}

 

== '''Bill Of Materials''' ==
{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Item#
! scope="col"| Part Description
! scope="col"| Part Model & Vendor
! scope="col"| Quantity
! scope="col"| Cost in USD
|-
! scope="row"| 1
| '''Microcontroller Boards'''
| SJ2 Boards (Purchased from Preet Kang)
| 4
| $200.00
|-
! scope="row"| 2
| '''CAN Transceivers'''
| [https://www.waveshare.com/sn65hvd230-can-board.htm Waveshare SN65HVD230]
| 12
| $54.48
|-
! scope="row"| 3
| '''RC Car'''
| [https://www.amazon.com/Traxxas-Slash-Course-2-4GHZ-Vehicle/dp/B01DU474B0/ref=sr_1_3?ie=UTF8&qid=1474747759&sr=8-3&keywords=Traxxas+1%2F10+slash+2wd Traxxas 2WD RTR with 2.4Ghz Radio]
| 1
| $260.00
|-
! scope="row"| 4
| '''Lithium-Ion Battery'''
| [https://www.rcsuperstore.com/traxxas-7600mah-2s-7-4v-25c-id-lipo-battery-pack/ Traxxas 7600mAh 2S 7.4V 25C iD LiPo Battery Pack]
| 1
| $75.00
|-
! scope="row"| 5
| '''Lithium-Ion Battery Charger'''
| [https://www.amazon.com/Traxxas-2970-EZ-Peak-Charger-Identification/dp/B00OAFYLJC/ref=pd_bxgy_21_img_2?ie=UTF8&psc=1&refRID=JVX791WVV9Y8T9DW92KW Traxxas 2970 EZ-Peak Plus 4-Amp NiMH/LiPo Fast Charger]
| 1
| $50.00
|-
! scope="row"| 6
| '''Compass Breakout Board'''
| [https://www.dfrobot.com/product-1275.html DFRobot CMPS11 Compass]
| 1
| $29.99
|-
! scope="row"| 7
| '''Bluetooth Breakout Board'''
| [https://www.amazon.com/HC-05-Bluetooth-Pass-through-Wireless-Communication/dp/B01G9KSAF6/ref=sr_1_4?ie=UTF8&qid=1507077325&sr=8-4&keywords=arduino+bluetooth+hc-05 DSD TECH Bluetooth HC-05]
| 1
| $8.49
|-
! scope="row"| 8
| '''LIDAR Sensor'''
| [https://www.amazon.com/RPLiDAR-A1M8-Degree-Laser-Scanner/dp/B07H7X3SFF/ref=sr_1_fkmrnull_1?crid=2FSUI76G4UA8K&keywords=rplidar+a1m8+-+360+degree+laser+scanner+development+kit&qid=1552764172&s=gateway&sprefix=RPlidar%2Caps%2C263&sr=8-1-fkmrnull SEEED STUDIO RPLIDAR A1M8]
| 1
| $109.99
|-
! scope="row"| 9
| '''RPM Sensor'''
| [https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM Traxxas 6520 RPM Sensor]
| 1
| $13.70
|-
! scope="row"| 10
| '''GPS Breakout Board'''
| [https://www.adafruit.com/product/746 Adafruit Ultimate GPS Breakout v3]
| 1
| $44.30
|-
! scope="row"| 11
| '''LCD Display'''
| [https://4dsystems.com.au/ulcd-32ptu 4Dsystems 3.2 TFT-LCD ULCD-32PTU]
| 1
| $79.00
|-
! scope="row"| 12
| '''Ultrasonic Sensors'''
| [https://www.amazon.com/gp/product/B01COSN7O6/ ELEGOO HC-SR04 Ultrasonic Module]
| 5
| $12.00
|-
! scope="row"| 13
| '''GPS Antenna'''
| [https://www.amazon.com/dp/B07RRT615K/ GPS Antenna A1-UX]
| 1
| $10.98
|-
! scope="row"| 14
| '''PCB Fabrication'''
| [https://jlcpcb.com/ JLCPCB]
| 5
| $40.15
|-
! scope="row"| 15
| '''Miscellaneous'''
| [https://www.amazon.com Amazon],[https://www.mouser.com/ Mouser Electronics],[https://www.digikey.com/ Digikey],[https://anchor-electronics.com/ Anchor Electronics]
| ~
| $48.07
|-
! scope="row"|
|
|
| '''Total'''
| '''$1036.15'''
|-

|}

 

== '''Printed Circuit Board''' ==

=== Design And Architecture ===
The complete PCB (for boards and hardware peripherals) was designed using EasyEDA online software. The 4 nodes will be communicating via CAN bus and other peripherals are connected to the PCB via headers.

=== Power Section===
We have 2 power banks supplying our system. And the Servo Motor, RPM sensor and DC rear Motor (via ESC) are powered using LiPo battery (6 volts).
* Power bank #1 - Subset 2

* Power bank #2 - Subset 1, Subset 3, Bluetooth

'''NOTE:'''

'''Subset 1:'''
1. LIDAR
2. LCD
3. Compass

'''Subset 2:'''
1. Motor node
2. Driver node
3. BS node

'''Subset 3:'''
1. Geo node
2. Back ultrasonic sensor

=== Fabrication ===
* PCB was sent to fabrication to JLCPCB China which provided PCB with MOQ of 5 and 2 layers of PCB with common grounded the entire copper area.
'''DRC elements'''
* Track Width = 12
* Clearance = 10
* Via Diameter = 24
* Via Drill Diameter = 12

=== Challenges ===
* Auto-routing gave lot of challenges (only ~60% success) and sometimes the online server even crashes and faces downtime. Even local routing had lot of issues. So make sure to plan your design accordingly.
* We started our PCB design well ahead of the project. So lot of pre-planning had to be done with regard to final hardware and placement of components in order to avoid spending extra time and money while re-ordering.
* The PCB went through a lot of internal revisions even before placing order. This was time-consuming.

'''Other hardware challenges:'''
* Figuring out why various hardware peripherals (GPS, Bluetooth, LIDAR and Ultrasonic sensor) started to malfunction (devices were on but values were either inconsistent / not occurring), took a lot of time to debug. It was due to insufficient power.

 

[[File:CMPE243 S20 T2 EasyEDA.png|1040x1200px|thumb|center|PCB Layout Design in EasyEDA]]
[[File:CMPE243 S20 T2 PCB SCHEMATIC.jpg|1041x550px|thumb|center|PCB Schematic]]

<div><ul>
<li style="display: inline-block;"> [[File:CMPE243 S20 T2 PCBFRONT.jpg|thumb|none|600px|PCB Top Layer]] </li>
<li style="display: inline-block;"> [[File:CMPE243 S20 T2 PCBBACK.jpg|thumb|none|600px|PCB Bottom Layer]] </li>
</ul></div>

 

== '''CAN Communication''' ==
<Talk about your message IDs or communication strategy, such as periodic transmission, MIA management, etc.>

=== Hardware Design ===
<Show your CAN bus hardware design>

=== DBC File ===

DBC FILE: [https://gitlab.com/coder137/can-ster_truck/-/blob/dbc-improvements/projects/lpc40xx_freertos/project.dbc Gitlab]

<pre>
VERSION ""

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

BS_:

BU_: DBG DRIVER IO MOTOR SENSOR GEO

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" GEO,MOTOR,SENSOR

BO_ 101 GEO_HEARTBEAT: 1 GEO
SG_ GEO_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,MOTOR,SENSOR

BO_ 102 MOTOR_HEARTBEAT: 1 MOTOR
SG_ MOTOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,SENSOR

BO_ 103 SENSOR_HEARTBEAT: 1 SENSOR
SG_ SENSOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,MOTOR

BO_ 200 MOTOR_STEERING: 1 DRIVER
SG_ MOTOR_STEERING_direction: 0|8@1- (1,0) [-2|2] "" MOTOR

BO_ 210 DRIVER_COORDINATES: 8 DRIVER
SG_ DRIVER_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
SG_ DRIVER_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 220 MOTOR_SPEED: 1 DRIVER
SG_ MOTOR_SPEED_processed: 0|8@1- (1,0) [-3|3] "" MOTOR

BO_ 300 GEO_DEGREE: 8 GEO
SG_ GEO_DEGREE_current: 0|32@1+ (0.000001,0) [0|360] "degrees" DRIVER
SG_ GEO_DEGREE_required: 32|32@1+ (0.000001,0) [0|360] "degrees" DRIVER

BO_ 310 GEO_DESTINATION_REACHED: 1 GEO
SG_ GEO_DESTINATION_REACHED_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 400 MOTOR_SPEED_FEEDBACK: 4 MOTOR
SG_ MOTOR_SPEED_current: 0|32@1+ (0.1,0) [0|60] "kph" DRIVER

BO_ 500 SENSOR_BT_COORDINATES: 8 SENSOR
SG_ SENSOR_BT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
SG_ SENSOR_BT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 510 SENSOR_SONARS: 8 SENSOR
SG_ SENSOR_SONARS_left: 0|21@1+ (0.001,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right: 21|21@1+ (0.001,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle: 42|21@1+ (0.001,0) [0|0] "cm" DRIVER

BO_ 520 SENSOR_LIDAR: 8 SENSOR
SG_ SENSOR_LIDAR_middle: 0|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_slight_left: 16|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_slight_right: 32|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_back: 48|16@1+ (1,0) [0|0] "cm" DRIVER

BO_ 530 MOTOR_KEY: 1 SENSOR
SG_ MOTOR_KEY_val: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 900 GEO_CURRENT_COORDINATES: 8 GEO
SG_ GEO_CURRENT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" DBG
SG_ GEO_CURRENT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" DBG

BO_ 901 GEO_DISTANCE_FROM_DESTINATION: 4 GEO
SG_ GEO_distance_from_destination: 0|32@1+ (0.001,0) [0|0] "meters" DBG

BO_ 902 MOTOR_INFO_DBG: 4 MOTOR
SG_ MOTOR_INFO_DBG_rps: 0|16@1+ (1,0) [0|0] "" DBG
SG_ MOTOR_INFO_DBG_pwm: 16|16@1+ (0.001,0) [0|0] "" DBG

BO_ 903 LIPO_BATTERY_VOLTAGE_DBG: 4 MOTOR
SG_ LIPO_BATTERY_VOLTAGE_val: 0|32@1+ (0.01,0) [0|0] "volts" DBG

BO_ 904 CURRENT_CHECKPOINT_DBG: 1 GEO
SG_ CURRENT_CHECKPOINT_val: 0|8@1+ (1,0) [0|0] "" DBG

CM_ "--BU (Network Node) Information--";
CM_ BU_ DRIVER "The driver controller of the car";
CM_ BU_ GEO "The geo controller of the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";

CM_ "--BO (Message) Information--";
CM_ BO_ 100 "Driver Sync message used to synchronize the controllers";
CM_ BO_ 101 "Geo Sync message used to synchronize the controllers";
CM_ BO_ 102 "Motor Sync message used to synchronize the controllers";
CM_ BO_ 103 "Sensor Sync message used to synchronize the controllers";

CM_ BO_ 200 "Steering direction values sent by Driver Node to Motor Node";
CM_ BO_ 210 "Driver Destination coordinates sent by Driver Node";
CM_ BO_ 220 "Required motor speed computed from Driver Node to Motor Node";

CM_ BO_ 300 "Current and computer/required degree values sent by Geo Node";
CM_ BO_ 310 "Indicator signal to check if the RC car has reached the destination";

CM_ BO_ 400 "Current motor info (rps and kph) sent as feedback to the Driver Node";

CM_ BO_ 500 "Coordinate BT values (destination coordinates) sent by Sensor Node";
CM_ BO_ 510 "LIDAR - Distance from obstacle detected in each sector";
CM_ BO_ 520 "Ultrasonic Sensor - Distance from obstacle detected by each sensor";
CM_ BO_ 530 "Start/Stop signal from the Bluetooth app";

CM_ BO_ 900 "Destination coordinates for BUSMASTER debugging";
CM_ BO_ 901 "Distance from destination";
CM_ BO_ 902 "Supplied PWM value to the motor and its RPM";
CM_ BO_ 903 "LIPO Battery Voltage";
CM_ BO_ 904 "Current checkpoint of the car";

CM_ "--SG (Signal) Information for Heartbeats--";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver node";
CM_ SG_ 101 GEO_HEARTBEAT_cmd "Heartbeat command from the geological node";
CM_ SG_ 102 MOTOR_HEARTBEAT_cmd "Heartbeat command from the motor node";
CM_ SG_ 103 SENSOR_HEARTBEAT_cmd "Heartbeat command from the sensor node";

CM_ "--SG (Signal) Information for DRIVER Node--";
CM_ SG_ 200 DRIVER_STEERING_direction "Calculated Driver Steering values (-2,2) for Motor";
CM_ SG_ 210 DRIVER_COORDINATES_latitude "Destination Latitude coordinate";
CM_ SG_ 210 DRIVER_COORDINATES_longitude "Destination Longitude coordinate";
CM_ SG_ 220 MOTOR_SPEED "Calculated Driver speed values (-3,3) for Motor";

CM_ "--SG (Signal) Information for GEO Node--";
CM_ SG_ 300 GEO_DEGREE_current "Current Geo Degree relative to true north";
CM_ SG_ 300 GEO_DEGREE_required "Calculated Geo Degree computed by Haversine Formula";
CM_ SG_ 310 GEO_DESTINATION_REACHED "Indicator signal to check if the RC car has reached the destination";

CM_ "--SG (Signal) Information for MOTOR Node--";
CM_ SG_ 400 MOTOR_SPEED_FEEDBACK "Feedback speed (kph) sent by Motor Node";

CM_ "--SG (Signal) Information for SENSOR Node--";
CM_ SG_ 500 SENSOR_BT_COORDINATES_latitude "Destination Latitude received over Bluetooth";
CM_ SG_ 500 SENSOR_BT_COORDINATES_longitude "Destination Longitude received over Bluetooth";
CM_ SG_ 510 SENSOR_SONARS_left "Ultrasonic Sensor attached to the left side";
CM_ SG_ 510 SENSOR_SONARS_right "Ultrasonic Sensor attached to the right side";
CM_ SG_ 510 SENSOR_SONARS_middle "Ultrasonic Sensor attached to the middle";
CM_ SG_ 510 SENSOR_SONARS_back_left "Ultrasonic Sensor attached to the back left side";
CM_ SG_ 510 SENSOR_SONARS_back_right "Ultrasonic Sensor attached to the back right side";
CM_ SG_ 520 SENSOR_LIDAR_middle "Lidar sensing the middle sector (-15 to 15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_left "Lidar sensing the slight left sector (-45 to -15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_right "Lidar sensing the slight right sector (15 to 45 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_back "Lidar sensing the back of the car (165 to 195 degrees)";
CM_ SG_ 530 MOTOR_KEY_val "1 -> Start the motor from the app, 0 -> Stop";

CM_ SG_ 900 GEO_CURRENT_COORDINATES_latitude "Current Latitude";
CM_ SG_ 900 GEO_CURRENT_COORDINATES_longitude "Current Longitude";
CM_ SG_ 901 GEO_distance_from_destination "Distance from destination";
CM_ SG_ 902 MOTOR_INFO_DBG_rps "Current RPS value of the motor";
CM_ SG_ 902 MOTOR_INFO_DBG_pwm "Supplied motor PWM value";
CM_ SG_ 903 LIPO_BATTERY_VOLTAGE_val "LIPO Battery Voltage";
CM_ SG_ 904 CURRENT_CHECKPOINT_val "Current checkpoint of the car";

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

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

BA_ "GenMsgCycleTime" BO_ 100 1000;
BA_ "GenMsgCycleTime" BO_ 200 50;
BA_ "FieldType" SG_ 100 DRIVER_HEARTBEAT_cmd "DRIVER_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 102 GEO_HEARTBEAT_cmd "GEO_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 103 MOTOR_HEARTBEAT_cmd "MOTOR_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 104 SENSOR_HEARTBEAT_cmd "SENSOR_HEARTBEAT_cmd";

BA_ "FieldType" SG_ 200 MOTOR_STEERING "MOTOR_STEERING";
BA_ "FieldType" SG_ 230 MOTOR_SPEED_val "MOTOR_SPEED_val";
BA_ "FieldType" SG_ 310 GEO_DESTINATION_REACHED_cmd "GEO_DESTINATION_REACHED_cmd";

VAL_ 100 DRIVER_HEARTBEAT_cmd 2 "DRIVER_HEARTBEAT_cmd_REBOOT" 1 "DRIVER_HEARTBEAT_cmd_SYNC" 0 "DRIVER_HEARTBEAT_cmd_NOOP" ;
VAL_ 101 GEO_HEARTBEAT_cmd 2 "GEO_HEARTBEAT_cmd_REBOOT" 1 "GEO_HEARTBEAT_cmd_SYNC" 0 "GEO_HEARTBEAT_cmd_NOOP";
VAL_ 102 MOTOR_HEARTBEAT_cmd 20 "MOTOR_HEARTBEAT_cmd_REBOOT" 10 "MOTOR_HEARTBEAT_cmd_SYNC" 0 "MOTOR_HEARTBEAT_cmd_NOOP" ;
VAL_ 103 SENSOR_HEARTBEAT_cmd 200 "SENSOR_HEARTBEAT_cmd_REBOOT" 100 "SENSOR_HEARTBEAT_cmd_SYNC" 0 "SENSOR_HEARTBEAT_cmd_NOOP" ;

VAL_ 200 MOTOR_STEERING_direction -2 "MOTOR_STEERING_hard_left" -1 "MOTOR_STEERING_slight_left" 0 "MOTOR_STEERING_straight" 1 "MOTOR_STEERING_slight_right" 2 "MOTOR_STEERING_hard_right";
VAL_ 220 MOTOR_SPEED_processed -3 "MOTOR_SPEED_reverse_fast" -2 "MOTOR_SPEED_reverse_medium" -1 "MOTOR_SPEED_reverse_slow" 0 "MOTOR_SPEED_neutral" 1 "MOTOR_SPEED_forward_slow" 2 "MOTOR_SPEED_forward_medium" 3 "MOTOR_SPEED_forward_fast";
VAL_ 310 GEO_DESTINATION_REACHED_cmd 1 "GEO_DESTINATION_REACHED_cmd_REACHED" 0 "GEO_DESTINATION_REACHED_cmd_NOT_REACHED";
</pre>

 

== '''Motor Controller''' ==
<Picture and link to Gitlab>

This controller is used to control the components of the car-related to motor. We can control the speed and steering of the car having interfaced with various components with the SJ-2 board. The servo motor is controlled via PWM and is used to set the steering direction of the car. The DC motor is controlled by the Electronic Speed Controller (ESC) via PWM for speed. We read the speed of the car by using an RPM sensor. By using the RPM sensor values, a feedback loop has been designed to regulate the speed of the car. A state machine has been designed to manage the forward and backward movements of the car.
Additionally, a voltage divider circuit has been implemented to read the battery voltage. All motor functionality and CAN message communication is run at 10 Hz.

=== Hardware Design ===

The following diagram details the hardware implementation of the motor module with the SJTwo board:
Hardware Interface
- Servo Motor
The servo motor responds to PWM pulses. It has three pins namely Vcc, PWM Input Signal, and GND. The servo is powered using 6V from the car battery. Based on the PWM signal supplied from the SJTwo board the front wheels are turned.
- Electronic Speed Controller (ESC)
The ESC is used to control the DC motor. It is supplied power using the 7.4 V LiPo battery. It has three pins namely Vout, PWM Input Signal, and GND. Based on the PWM input signal, the speed and forward, neutral, and backward movements of the car is changed. Vout is given to the RPM sensor and Servo motor.
- DC Motor
The DC motor is controlled using the ESC. It has two pins, a positive and negative terminal. A PWM signal wire is connected to the microcontroller and the required current is provided by the LiPo battery and the ESC. The DC motor is controlled using PWM at 10Hz.

[[File:CMPE243_S20_T2_Canster_Truck_Motor_Hardware.png|thumb|center|750px| Motor Hardware System]]

Note: First calibrate the DC motor or the motor will not respond to your PWM pulses. For help with calibration go to this [https://traxxas.com/support/Programming-Your-Traxxas-Electronic-Speed-Control website]

- RPM Sensor

The RPM sensor is used to get the current speed of the car. We use the info for creating a feedback loop (PID) for maintaining the speed of the car in uphill and downhill situations. The RPM sensor mounts on the rear DC motor shaft compartment with a special assembly also provided by Traxxas. The magnet which attached to the inner gear generates a pulse each rotation. The sensor works on the hall effect principle where it provides a current across its terminal when placed in a magnet's field. The RPM sensor has three pins namely Vcc, Signal, and GND.

- Battery Voltage Divider Circuit
- (Need Niket’s help)

=== Software Design ===

The software for the motor node was divided into multiple files and made modular to improve readability and understanding of the complex logic involved. The main code modules are for:
• Servo Motor
• Electronic Speed Controller
• RPM Sensor
• Motor Wrapper
• Battery Voltage

The motor wrapper module is used to wrap all the code from the esc, servo, and rpm modules into simple to use functions to be called in the periodic tasks.
• Servo Motor
It uses the steering value sent from the driver (-2 to 2) and matches it to the appropriate PWM value for steering. This code module is run at 10Hz.
<pre>
void servo__steer_processor(int16_t steering_value) {
switch (steering_value) {
case MOTOR_STEERING_hard_left:
servo__steer_hard_left();
break;
case MOTOR_STEERING_slight_left:
servo__steer_soft_left();
break;
case MOTOR_STEERING_straight:
servo__steer_straight();
break;
case MOTOR_STEERING_slight_right:
servo__steer_soft_right();
break;
case MOTOR_STEERING_hard_right:
servo__steer_hard_right();
break;
default:
printf("\nDid not receive steering value");
}
}
</pre>
• Electronic Speed Controller

This code module is used to control the DC motor. It receives the motor direction value from the driver and sets the appropriate PWM value. Based on the value the motor is commanded to move the car forward or backwards. A switch case is implemented to set PWM values for movement in different directions along with different speeds.
<pre>
void esc__direction_processor(int16_t direction_value) {
desired_direction_value = direction_value;
switch (direction_value) {
case MOTOR_SPEED_reverse_fast:
esc__reverse_fast();
break;
case MOTOR_SPEED_reverse_medium:
esc__reverse_medium();
break;
case MOTOR_SPEED_reverse_slow:
esc__reverse_slow();
break;
case MOTOR_SPEED_neutral:
esc__neutral();
break;
case MOTOR_SPEED_forward_slow:
esc__forward_slow();
break;
case MOTOR_SPEED_forward_medium:
esc__forward_medium();
break;
case MOTOR_SPEED_forward_fast:
esc__forward_fast();
break;

default:
printf("\nDid not receive direction and speed value");
}
}
</pre>

There is also a feedback loop to control the speed. The ESC code depends on the rpm sensor code for the current speed values.
<pre>
double current_speed = get_speed_kph();
double desired_speed = desired_speed_kph;
float adjusted_duty_cycle = 0.0;
adjusted_duty_cycle = duty_cycle + (speed_to_pwm_adjustment(desired_speed, current_speed));
</pre>

[[File:CMPE243_S20_T2_Canster_Truck_Motor1.png|thumb|center|400px| Motor Flowchart 1]]

• RPM Sensor
This code module is used to get current speed data from the RPM sensor. It is based on interrupts. When the wheel rotates once, we get one pulse due to the magnet installed. This pulse generates a falling edge interrupt during which we increment the pulse counter. Since, this code is run at 1Hz we collect the number of pulses generated every one second. This gives us the number of rotations per second using which we can calculate the speed in kph.
<pre>
float rpm__calculate_speed_kph() {
uint16_t rotation_per_sec = pulse_count;
pulse_count = 0;
speed_kph = ((CIRCUMFERENCE_METER * rotation_per_sec) * (MPS_TO_KPH_CONVERSION_FACTOR)) / GEAR_RATIO;
return speed_kph;
}
</pre>

• Motor Wrapper
As mentioned above, the main function of this code module is to wrap all the other code modules and call the right functions at the appropriate frequency. The motor wrapper code also includes a state machine for ensuring a smooth transition between forward to backward state and vice versa. In order to achieve a smooth transition, a series of PWM pulses must be generated at the right time. For example, when the motor is moving from forward to backward state, a reverse value must be given first followed by at least three neutral values, and then continue with reverse values.

[[File:CMPE243_S20_T2_Canster_Truck_Motor2.png|thumb|center|400px| Motor Flowchart 2]]

=====LIPO Battery Voltage=====
The LIPO Battery Voltage was calculated using ADC in Burst Mode. A LIPO Hardware module was created for the same which contained two functions, <code>lipo__init</code> and <code>lipo__get_voltage</code>.

The voltage divider circuit is stepped down from 7.4V to 2.1V using 10K and 4K Resistor pair.

'''LIPO Initialization'''

The LIPO Initialization phase initializes the ADC, Enables Burst mode on the ADC pins and configures the Alternate Function Registers for the same.

'''LIPO Get Voltage'''

We read the raw ADC value from the LPC Hardware register. This value will be from 0 - 3.3V. However due to our voltage divider configuration the max voltage that we should theoretically get is 2.1V. This means that 2.1V corresponds to 7.4V of the LIPO Battery voltage.

The formula used is
<code>(raw_adc_value * MAX_LIPO_BATTERY_VOLTAGE_VALUE) / MAX_LIPO_ADC_VALUE</code>

=== Technical Challenges ===
<ol>
<li>Changing movements of the car from Forward to Backward and vice versa
If you just change the PWM value from say 16 (Forward) to 14(Backward), the DC motor will just stop and will not make wheels turn reverse. We discovered this problem quite late as during the initial testing we had always run the car from the start with either forward or reverse but never tried changing the direction during run-time.
Solution: The motor requires a series of PWM pulses which is specific to the car to transition from forward mode to reverse mode. In our case we had to give the PWM pulses in the following sequence. Suppose,
<ol>
<li> Forward (16) (callback_count=0)</li>
<li> Forward (16) (callback_count =1)</li>
<li> Reverse (14) (callback_count =2)</li>
<li> Neutral (15) (callback_count = 3)</li>
<li> Neutral (15) (callback_count = 4)</li>
<li> Neutral (15) (callback_count = 5)</li>
<li> Reverse (14) (callback_count = 6)</li>
<li> Continue reverse</li>
</ol>
Similarly, the reverse to forward can also be implemented.
<li>DC motor shooting off when there is an improper ground connection
When we connected the battery voltage circuit for reading the voltage from the battery, the motor would randomly shoot off every now and then.
Solution: Connect the voltage divider circuit to the common ground rather than taking the ground from the ESC.</li>
</ol>

<HR>
 

== '''Geological Controller''' ==

<Picture and link to Gitlab>

===Messages===
*GEO_HEARTBEAT: Used to check for MIA by other nodes. Highest priority message for GEO Node

*GEO_DEGREE: Sends the current degree relative to the North Pole computed by the Compass and the Required degree relative to the North Pole computed by Bearing Angle using the Current Coordinate and Destination Coordinate.

*GEO_DESTINATION_REACHED: Sets a flag, 0 for destination not reached and 1 for destination reached

*GEO_CURRENT_COORDINATES: Debug Message used to send the Current GPS Coordinates

*GEO_DISTANCE_FROM_DESTINATION: Debug message used to send the Distance from Destination

*CURRENT_CHECKPOINT_DBG: Debug message used to check which checkpoint is being navigated to

=== Hardware Design ===

[[File:CMPE243_S20_T2_GEO1.png|thumb|center|650px| Geological Diagram]]

=== Software Design ===
=====Overview=====
*Inside the `periodic_callback__initialize`
**Initialize the CAN BUS
**Initialize the GPS

*Inside the `periodic_callback__1hz`
**Handle all MIA (from other Nodes)
**Update GPS LED when init and in case of failure
**Compute the GEOLOGIC for Waypoints algorithm once every second (1000 ms)

*Inside the `periodic_callback__10hz`
**Handle CAN Incoming messages (Decode)
**Transmit CAN Geo messages (Encode and send)
**Compute the GPS Coordinate

=====Compass I2C Driver=====
An online datasheet resource was used to work with the Compass (https://www.robot-electronics.co.uk/htm/cmps11i2c.htm)
Initially the Compass I2C Driver was tested using the Terminal I2C Helper built by our Professor Preetpal Kang. Using this resource we were quickly able to read various I2C Registers and display it onto the terminal.

For our project the only required part of the Compass was the 16-bit Compass Bearing value (0-3599) i.e 0-359.9 degree values. These values were stored in the 2nd and 3rd register (Register 2 being the High Byte).
Once the raw data was received over I2C we could easily combine the data

<pre>
uint16_t bearing_value = (Reg2 << 8) | Reg3;
float rval = bearing_value / 10.0;
return rval;
</pre>
The returned value were transmitted to the Driver Node to compute its steering based on the required Bearing Angle.

=====GPS Initialization=====
GPS Initialization activates the Hardware GPIO (RX and TX), FreeRTOS Queue for UART Interrupts (UART Module) and Line Buffer Module to parse each GPS line.

=====GPS Data Parsing=====
The GPS Hardware module transmits an NMEA string over UART to the SJTwo Board. We read each character one by one and add it to the Line Buffer module.
Inside its computation loop, the Line Buffer module checks if a newline character has been received.
When a newline character has been received the entire string is extracted from the line buffer module and parsed according to its identifier ($GPRMC, $GPGGA) received and parsed into individual tokens.
For our purposes the $GPRMC NMEA string was the most appropriate and it helped us extract the Current Latitude Longitude as well as the Valid/Invalid tag for the Canster Truck.

=====GPS LED Indication for debugging=====

A simple module that checks for the GPRMC GPS Message and extracts the A or V valid (Tag). If $GPRMC NMEA string is valid, LED is set, else LED is reset. This gives us onsite debugging capabilities to know if GPS has locked onto a satellite signal.

=====GEO Logic Module Computation=====
The GEO Logic Module computes the Bearing Angle, Haversine Distance as well as the Waypoints algorithm.

'''Bearing Angle:'''

<code>
θ = atan2( sin Δλ ⋅ cos φ2 , cos φ1 ⋅ sin φ2 − sin φ1 ⋅ cos φ2 ⋅ cos Δλ )
</code>

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

Since atan2 returns values in the range -π ... +π (that is, -180° ... +180°), to normalize the result to a compass bearing (in the range 0° ... 360°, with −ve values transformed into the range 180° ... 360°), convert to degrees and then use (θ+360) % 360, where % is (floating point) modulo.
For final bearing, simply take the initial bearing from the endpoint to the start point and reverse it (using θ = (θ+180) % 360).

The above article reference gives us the required bearing angle that our car must align itself to, to reach a particular destination coordinate from its current coordinate.
The Steering of the Canster Truck depends on the above-computed angle values.

'''Haversine Distance Formula:'''

This uses the ‘haversine’ formula to calculate the great-circle distance between two points – that is, the shortest distance over the earth’s surface – giving an ‘as-the-crow-flies’ distance between the points (ignoring any hills they fly over, of course!).

<code>
a = sin²(Δφ/2) + cos φ1 ⋅ cos φ2 ⋅ sin²(Δλ/2)

c = 2 ⋅ atan2( √a, √(1−a) )

d = R ⋅ c
</code>

where φ is latitude, λ is longitude, R is earth’s radius (mean radius = 6,371km);
note that angles need to be in radians to pass to trig functions!

The above formula is used to calculate the distance between the source coordinate (received via GPS) and the destination coordinate.
Later this was used to compute the distance between source coordinate and each individual checkpoint to traverse the shortest distance.

'''Waypoints Algorithm:'''

The Waypoints algorithm that was chosen was a slightly modified version of Djikstra’s Algorithm.
3 values were calculated before the final computation
- Distance between source and final destination (DISTsd)
- Distance between source and each individual checkpoint (DISTsc)
- Distance between each individual checkpoint and the final destination. (DISTcd)
If DISTsd was lesser than DISTcd, this checkpoint was discarded (we continue in the loop). Since we would be moving in the opposite direction, rather than towards the final destination.
If DISTsd was greater than DISTcd, then we checked the nearest checkpoint to the source.
The minimum value was set initial that was equal to DISTsd.
If DISTsc was lesser than the minimum value stored, DISTsc would become the new minimum value, and the checkpoint index and coordinates would be appropriately stored and returned from the function.
In this way we would navigate to the nearest checkpoint from the source, while also making sure NOT to travel in the opposite direction.
This logic is recomputed only when we reach the checkpoint selected and the algorithm runs again to find the next checkpoint that we need to navigate to.

=====CAN Decode Destination Coordinates=====
Destination Coordinates are received from the Bridge and Sensor Node and transmitted over the CAN Bus. The value is decoded and stored in the GEO Logic Module.
This is a very important value since our entire GEO Logic calculations are based on the Destination Coordinate.

=====CAN Encode and Send=====

The main messages that were transmitter are
#Geo Degree
#Geo Destination Reached
#Distance from Destination Debug and Checkpoint Index debug

'''Geo Degree Computation as per Waypoints Algorithm:'''

Geo Degree was computed as per the current coordinates and the most recently computed checkpoint coordinates. This bearing angle calculation w.r.t computed checkpoint would continue till we do not reach that particular checkpoint.
Once we reach the computed checkpoint, Waypoint algorithm is recomputed as per the process mentioned above and the algorithm runs again.

'''Geo Destination Reached:'''

An Area of around 4 meters was set around the destination coordinate to check if the destination had been reached.
This measurement was taken into consideration to allow for the loss in precision when transmitting data over CAN as well as any irregularities that might occur when getting values from the GPS.
Having an area of 4 meters was very accurate for all of our test runs.

'''Geo Distance from Destination Debug and Checkpoint Index Debug:'''

Getting debug information was very critical to speed up our development process. In this case we could actively see if our algorithm worked properly.
The Geo Distance from Destination was used to see if we were moving closer to our destination or veering further away from it.
The Checkpoint Index was used to see which checkpoint index we were traveling to. By knowing the placements of the Individual checkpoints we could manually as well as programmatically (via Android application) verify the working of our Canster Truck.

=== Technical Challenges ===
#DBC Challenge for GEO Coordinates -> Could not encode more than 5-6 decimal places at a time, on later investigation we found that the 10000 is an int value, however 100000 overflows the int value.
#Creating an efficient algorithm for Waypoints, O(n) complexity.
#Getting appropriate fixes for GPS when not in a completely open space.
#GPS used to fluctuate or stop giving values when Battery voltage went below a particular threshold. Always supply 3.3V constantly at a good amperage.

<HR>
 

== '''Sensor [Bridge and Sensor Controller]''' ==
<Picture and link to Gitlab>

==='''Ultrasonic Sensor'''===
====Hardware Design====
This sensor uses an ultrasonic beam to measure the distances. Based on the time taken between when the beam is sent and received back to the sensor, the distance is calculated in the node.
Apart from 5v and GND, this sensor has 2 pins ECHO and TRIG which are interfaced with the SJ-Two board via GPIO.

[[File:CMPE243_S20_T2_CansterTruck_ultrasonic_sensor.jpg|thumb|center|300px| Ultrasonic Sensor Diagram]]

====Software Design====
* Init the GPIO pin connected to TRIG of the sensor as output and for ECHO as an input port.
* Attach the interrupt on the ECHO input port.
* Store the system_clock_count before setting the trigger pulse and then set the pulse. Also keep monitoring the input port.
* Take the system_clock_count at the instant of receiving the interrupt.
Distance = (system_clock_count_at_trig - system_clock_count_after_at_echo) / 57.14

==='''Lidar Sensor'''===
====Hardware Design====
The RPLidar sensor can be powered from a 5-volt source and uses UART communication to receive commands and transmit data. It has seven pins to interface with. Two sets of the pins (four total) are for power and ground. The remaining three are for UART receive and transmit, and for making the lidar’s motor spin.

[[File:CMPE243_S20_T2_Canster_Truck_RPLidar_A1.JPG|thumb|center|300px| RPLidar A1]]

====Software Design====
In terms of the lidar, the SJ2 initializes GPIO, UART, and memory for storing the measurement values. After initialization, the command to begin scanning is sent. Here, we wait for the lidar to send a response packet, letting the host (SJ2 board) know it received the command. The response packet the lidar sends will be 7 bytes. If the correct 7 bytes are not received, the command will be sent again.

[[File:CMPE243_S20_T2_Canster Truck_Lidar_flow.jpeg|thumb|center|200px| Lidar Flow]]

Following the response packet, the lidar begins sending 5-byte measurement data. Each sample contains a distance measurement (in millimeters) and the angle (with respect to the lidar) in which it was taken. The data packet structure is shown in the following figure. In addition to containing the distance and angle, the packet includes a quality value, to indicate the reliability of the measurement, and three check bits (S, ~S, and C). As the data is received via UART, we wait until we have 5 bytes before continuing to process. Before processing the 5 bytes after receiving them, the check bits are confirmed to be correct. If they are incorrect, it will not be processed and we will wait for another sample to be received.

[[File:CMPE243_S20_T2_Canster Truck_DataPacketStructure.JPG|thumb|center|200px| Data Packet Structure]]

In the case the sample is correct, each measurement value that is in a direction of interest will be placed in an array designated to one of four directions (left, right, front, rear). Each of these directions have their own sector in the lidar’s 360-degree view.
*Right sector: 11°-30°
*Rear sector: 170°-190°
*Left sector: 330°-349°
*Front sector: 350°-370° (or 10°)

The arrays mentioned will hold roughly 20 measurements, which are every degree in the sector. In the event, objects are too far to measure, the lidar will report 0 mm. distance. Since there is no measurable obstacle, a “large” distance value of 3000 mm. is placed in the array. The smallest distance value will be taken from each array and reported to the driver node for obstacle avoidance.

=== Technical Challenges ===
====Ultrasonic====
====Lidar====
*'''Datasheet not 100% clear:''' The correct datasheet for the was a bit difficult to obtain, and the manufacturer needed to be contacted. The first document found online was high level and general information about the sensor, but the manufacturer did provide another document that contained the information of the commands and responses to and from the lidar, and their packet structure. The documents did not clearly state the angles with respect to the lidar are fixed, which left me wondering if the lidar will think the direction it is facing when powered on will become the new “zeroth” angle.

*'''UART Buffer Overflow:''' When first interfacing with the sensor, the incoming bytes of the lidar were printed on to the terminal to make sure there was a response and to make sense of the information. Since the command we sent results in 5 bytes of data per measurement samples from the lidar and the lidar measured 2000 times per second, there are will be roughly 10k Bytes per second of data incoming that need to be handled continuously. With an improperly sized UART buffer and print statements it is guaranteed to occur, making the lidar data look like random values.

*'''Proper Parsing of Measurement Data:''' After sending a command to the lidar, the sensor will send a response packet, followed by the measurement data. The initial response from the lidar is a 7-byte packet, followed by continuous 5-byte measurement samples. I needed to make sure however I handled the response would be independent of how the measurement is handled, so as not to create a potential unwanted offset when receiving measurements.

*'''Object Detection with Received Data:''' Once proper communication was set up with the lidar and measurement data was getting decoded, there needed to be a way to measure when obstacles were present. If ~360 measurements are handled entirely independently from one another, it could become a complex and confusing code. To achieve a simple approach, four sectors about 20 degrees in size were used to represent the front, left, right, and rear directions.

*'''Bugs in Code:''' When first implementing the code, there were a few bugs from typos, incorrect numbers, and some faulty logic that were found with the use of unit testing. Unit testing helped find these issues and verified the logic was correct, and I would say gave me 90% confidence in my lidar handling.

<HR>
 

== '''Bridge [Bridge and Sensor Controller]'''==
<Picture and link to Gitlab>

Bridge functionality of the Bridge and Sensor Controller is to establish wireless communication between the SJ-2 Board and the android mobile device using the HC-05 Bluetooth module. The Bridge controller will be receiving start command with destination GEO coordinates and stop command. The Bridge controller will be transmitting the required sensor data and debug information to be displayed on the android application.

[[File:CMPE243_S20_T2_BRIDGE.png|thumb|center|500px| Bridge Diagram]]

===Bluetooth===

==== Software Design ====

'''Low-Level Layer'''

In this layer, similar to the GPS the UART GPIO was initialized (RX, TX), FreeRTOS Queue was initialized for UART Interrupts and the line buffer module was initialized to parse strings.

Two basic functions <code>bt__read</code> and <code>bt__write</code> were implemented.
As the name suggested, <code>bt__write</code> took a string as its input parameter and transmitted that data to the Android application. <code>bt__read</code> stored the incoming characters into the line buffer, parsed the line received into its identifier and tokens, and invoked a callback function.

Since this was a low-level layer the User would not be directly invoking this library. Instead a '''Bluetooth Wrapper''' module was created which would be invoked and used by the user.

'''Application Layer'''

The Bluetooth Wrapper module had the appropriate <code>read_once</code> and <code>write_once</code> functions.

The <code>read_once</code> function internally just called the <code>bt__read</code> function. All of the decodings was done inside the Callback Function.
To get the Destination coordinate the string received from the Android Application was in the form of
<code>$loc,<destination_latitude>,<destination_longitude>.</code>
Upon receiving this data we parsed the destination_latitude and destination_longitude, which could later be accessed using getters.
We also set a start flag to notify the Driver Node that destination has been received and we can start steering towards our checkpoints.

Another command implemented was the stop command.
<code>$stop</code>
This was used to send a stop flag to the Driver node.

The <code>write_once</code> function used the getter methods from each CAN Decode message and update its internal state variables. A CSV String was created using the <code>$canster</code> identifier and various debugging points were appended to this message using a comma.
On the Android application side this CSV string was tokenized and displayed onto the Application Debug screen appropriately.

==== Technical Challenges ====

<List of problems and their detailed resolutions>

<HR>
 

== '''Driver [Driver and LCD Controller]''' ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===

[[File:CMPE243_S20_T2_Canster Truck_Driver_Flowchart.png|thumb|center|750px|Driver Flowchart]]

The above block diagram explains the process flow of obstacle detection for the car. The LIDAR detects
the obstacle and depending on the distance of obstacle the car takes a slight right and slight left or a
hard right and hard left. The state of the car also depends on the value of the LIDAR and ultrasonic sensor.
The loose ends of the LIDAR for the reverse condition are checked by the ultrasonic sensors. The
The ultrasonic sensor works on the principle of trigger and echo and can detect the obstacles very close by.
The range of the Ultrasonic sensor is lower than the LIDAR. Finally, if no obstacle is detected the car goes
straight until the destination is reached. The speed of the car is also various when an obstacle is detected to
avoid the crash and the car’s smooth transition from one state to another. The key to the android
application controls the start and stop the process of the car. If the key is not pressed, then the stays in the

neutral state. The speed of the car is controlled by the changing duty cycle of the input voltage. There
are seven-speed levels in which the motor can run on. These speed levels are Forward Slow, Medium,
Fast, Reverse Slow, Medium, Fast, and Neutral. The Neutral is the stop condition with a 0% duty cycle.

=== Technical Challenges ===

< List of problems and their detailed resolutions>

<HR>
 

== '''LCD [Driver and LCD Controller]''' ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
The GLCD used was created by 4DSystems, using their IDE a UI was created. Each UI component could be controlled by sending UART data targeted at the widget address.
The best part about this GLCD was that we had a lot of interactive widgets to display debugging information in real-time.
The GLCD code was divided into 3 parts:
<ol>
<li>'''Low-Level Initialization'''
Initialize the low-level hardware interfaces to send and receive data from the GLCD.
Similar to the GPS and Bluetooth, The UART GPIO was initialized (RX, TX), FreeRTOS Queue was initialized for UART Interrupt and line buffer was used to get a stream of data for parsing.

Low-level '''read''' and '''write''' commands were used as per the working of the GLCD Module.
When Reading data pertaining to a widget on the GLCD we would need to send a particular response packet.
<pre>
void lcd__read(lcd_object_e object_id, uint8_t object_index, uint8_t *response, uint16_t *response_data) {

uint8_t checksum = READ_OBJ ^ object_id ^ object_index;
uint8_t buffer[] = {READ_OBJ, object_id, object_index, checksum};

lcd__write_data(buffer, sizeof(buffer) / sizeof(uint8_t));
lcd__read_response_id(response);
lcd__read_response_data(response_data);
}
</pre>

The response_data returned contains the Widget ID as well as the current value stored on that widget.

When Writing data pertaining to a widget on a GLCD the process is similar to the above mentioned code.
<pre>
void lcd__write(lcd_object_e object_id, uint8_t object_index, uint8_t msb, uint8_t lsb, uint8_t *response) {
uint8_t checksum = WRITE_OBJ ^ object_id ^ object_index ^ msb ^ lsb;
uint8_t buffer[] = {WRITE_OBJ, object_id, object_index, msb, lsb, checksum};

lcd__write_data(buffer, sizeof(buffer) / sizeof(uint8_t));
lcd__read_response_id(response);
}
</pre>

However in this case we receive only an ACK or NACK from the system. ACK would mean that the write to GLCD widget was successful and the widget now stored appropriate values. NACK would mean that a particular error has occurred. The errors could be regarding baud rate, incorrect bit format, incorrect index values, etc.
</li>
<li>'''GLCD Wrapper for Widgets'''
The above low-level code had generic read and write functions. However for our UI we were only using 3 Widgets. All of which had '''different Indexes''' and '''Widget IDs'''.
Therefore a very simple library was created to easily interface with those widgets
<pre>
bool lcd_wrapper__read_led(uint8_t index);
uint16_t lcd_wrapper__read_meter(uint8_t index);
uint16_t lcd_wrapper__read_leddigit(uint8_t index);

bool lcd_wrapper__write_led(uint8_t index, bool value);
bool lcd_wrapper__write_meter(uint8_t index, uint16_t value);
bool lcd_wrapper__write_leddigit(uint8_t index, uint16_t value);
</pre>

The above code is self-explanatory read and write functions for '''LED''', '''METER''', and '''LED DIGIT'''.
</li>
<li>'''GLCD UI'''
Now that we had our low level and Widget wrapper working properly, we wanted to create our Dynamic UI as well. The code would need to be robust enough to handle any UI that we create on the GLCD which could be reflected equivalently in our C Code.

<pre>
static void lcd_ui__update_ui(void) {

lcd_wrapper__write_led(LCD_LED_DRIVER_MIA_INDEX, driver_mia_led);
lcd_wrapper__write_led(LCD_LED_SENSOR_MIA_INDEX, sensor_mia_led);
lcd_wrapper__write_led(LCD_LED_GEO_MIA_INDEX, geo_mia_led);
lcd_wrapper__write_led(LCD_LED_MOTOR_MIA_INDEX, motor_mia_led);

// kph is always in the range of 0 - 10
lcd_wrapper__write_meter(LCD_METER_KPH_INDEX, kph_meter % 11);

// These will be in the Range of 0-99
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_RPM_INDEX, rpm_leddigit % 100);
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_CURRENTDEGREE_INDEX, cdegree_leddigit % 100);
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_REQUIREDDEGREE_INDEX, rdegree_leddigit % 100);
}
</pre>

As we can see the `lcd_ui__update_ui` function was called periodically inside the 1Hz function. It updated the screen in real time based on the static values that were stored AND updated inside the LCD UI module.
The Constant INDEX values stored were directly mapped onto the Index values were received from the 4DWorkshop UI Software.
</li>
</ol>

=== Technical Challenges ===

< List of problems and their detailed resolutions>

<HR>
 

== '''Android Application''' ==
[https://gitlab.com/akhilcherukuri/can-ster_truck_application Gitlab]
=== Software Design ===

<div><ul>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android1.jpg|thumb|none|250px|Splash Screen]]</li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android2.jpg|thumb|none|250px|Main Activity Screen]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android3.jpg|thumb|none|250px|Map Activity Screen]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android4.jpg|thumb|none|250px|Info Activity Screen 1]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android5.jpg|thumb|none|250px|Info Activity Screen 1]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android6.jpg |thumb|none|250px|Debug Activity Screen]]</li>
</ul></div>

The application consists of a total of 5 Activities:

*'''Main Activity:'''
**This is the app launch display screen
**It will check for all the required permission onStart().
**Has search button for connecting from a paired device list view
**Once device is clicked, an intent will start the Map Activity
*'''Map Activity:'''
** For this requirement we are using the Google Maps Fragment, for the map fragment to function we must request an API key from Google and set the key in the manifest of the application.
** Destination marker(Red Marker) is set using setOnMapClickListener to which the car will navigate to, the destination can be changed by clicking elsewhere on the Map Fragment. The marker can be removed using setOnMarkerClickListener.
** When the start button is pressed, the start command identifier along with destination latitude and longitude is sent to the car via the write thread. A background thread is started along with it to indicate the current car's position(Green Marker) along with a plotline between the current position and destination.
** When the stop button is pressed, the stop command identifier is sent to the car, to stop and turn off the car.
*'''Info Activity:'''
** Messages from Geological, Driver, Motor coming from CAN bus are decoded by the Sensor and Bridge controller and sent to the Android application as a string.
** The received string is parsed and categorizes the data to store it in the required textView to be displayed.
** Bluetooth status, Lidar Values, Ultrasonic Sensor Values, Motor Speed, Motor RPM, Motor PWM, Cars' current location, Compass Heading, Distance till Destination, Checkpoint Index is displayed. This was useful for debugging purposes and allowed us to avoid scanning the mounted LCD or CAN Busmaster on PC during drives.
*'''Debug Activity:'''
**The main function of this activity is to check all RAW RX and RAW TX messages and create a log of all the data received and sent.
*'''Bluetooth Connection Service Activity''' :
**This is the background activity that handles all the threads required for transmission and receiving data using Bluetooth connections. It has 3 running threads which is called inside other activities using a handler:
** Accept Thread - Listens to BluetoothServerSocket using listenUsingRfcommWithServiceRecord. In order for the RF communication socket to connect to the HC-05, we used the following UUID: 00001101-0000-1000-8000-00805F9B34FB. This is a generic SSP Bluetooth UUID that enables the socket to directly connected to HC-05 and maintain the connection.
** Connect Thread - Creates a Bluetooth socket using createRfcommSocketToServiceRecord
** Connected Thread - Creates socket.getInputStream(); and socket.getOutputStream(); when bytes are available in input stream it will read them into a buffer.
***All messages for activities are done by Handler mHandler.obtainMessage(); mHandler.sendMessage();

*'''Receieved string''':
** A String is sent to the Bluetooth app from HC-05 and when it receives a string with identifier "$canster", the message is prased accordingly by using the string delimiter ',' and is ended by the newline character '\n' which will remove the data from StringBuffer.
** Example: $canster,37.339334,-121.881123,37.338713,-121.880685,10.123,20.133,30.123,10.5,88.1,99.2,-2,1,44,7,11,22,33,-3,23\n

[[File:CMPE243_S20_T2_BLUETOOTHFLOWCHART.png|thumb|center|650px| Android Application Flowchart]]

=== Technical Challenges ===

<HR>
 

== '''Mangaement''' ==
===Team Management ===
===Git Management===

Git Management amongst 6 team members was definitely a very challenging task. Depending on our initial design we could’ve had a lot of merge conflicts. However those risks were mitigated by spending a LOT of time in the initial stages to decide our pipeline and structure.

<li>There are certain components in our system that were COMMON. For example the CAN initialization, communication and decodes were all similar for the most part between all the 4 Controllers. The utility modules used were also similar in nature</li>
<li>Thus we made a common branch that contained the templates for CAN Nodes (not Controllers), Hardware code and Utility functions.
<ol>
<li>Later this common branch was forked into an individual Controller specific branch (SENSOR, GEO, MOTOR or DRIVER).</li>
<li>Only the Logic folder contained Controller specific code, specific to that controller.</li>
</ol>
<li>This gave us a lot of flexibility since all the team members had similar APIs to work with on all 4 branches. This promoted easy understanding and learning.
<ol>
<li>Many team members frequently worked on 2 or more controllers at a time where can messages were concerned. Having a APIs also meant that just the can_handler needed to be updated regularly followed by the equivalent logic code. </li>
<li>Inside the logic folder, getters to the can node modules were frequently used.</li></ol>
<pre>
├───can_module
│ ├───can_bus_initializer
│ ├───can_constants
│ ├───can_driver_node
│ ├───can_geo_node
│ ├───can_handler
│ ├───can_motor_node
│ ├───can_sensor_node
│ └───test
├───hardware
│ ├───bt
│ ├───compass
│ ├───gps
│ ├───lcd
│ ├───test
│ └───ultrasonic
├───logic
│ ├───driver_obstacle
│ ├───driver_state
│ ├───geo_logic
│ └───test
├───periodics
│ └───test
└───utility
├───line_buffer
└───test
</pre>

'''Challenges'''
<li>It was initially a bit of a learning curve to understand the flow of the repository</li>
<li>When using a git management system with different versions in each branch it became very tough when the number of branches suddenly exploded in size. A lot of relevant code was stuck in a lot of different branches.
<ol>
<li>This happened mainly due to assignment submissions and unclosed MRs that eventually became stale.</li>
<li>Our strategy was to abandon these MRs and keep forking from these branches without merging it back into its final controller branch.</li>
<li>The latest branches that were kept were aptly named `<controller>_bleeding_edge_dev` branches since they were never merged back from where they were forked.</li>
</ol>
<li>Since a lot of our code also depended on the DBC autogenerated code, we could not suddenly change the DBC Message names once they were established since it caused a change in the Struct name that was generated and used.
<ol>
<li>Our solution to this was to keep everything backward compatible. We added new function names without deleting old DBC messages.</li>
<li>In certain places where we wanted to modify a function name it was done one by one so that a lot of the code is not broken at one time.</li>
</ol>
<li>Common Branches eventually became stale as our progress continued on the bleeding edge branches
<ol>
<li>For example certain GPS features needed to be added which were done on the GEO_bleeding_edge_dev branch but never pushed or cherry-picked back into the COMMON branch.</li>
<li>This was a similar issue to our 2nd point but manageable since the goal of the COMMON branch was to provide a template for further work and nothing more.</li>
<li>At the end of the day each controller is its own Individual Project and while the messages between them are same. The Hardware code does not need to be same.</li>
<li>This also prompted team-members to ask if we could delete unused hardware or logic file code (which wasn’t being used and was imported from the template). This was also fine and can be done during cleanup stage. However we eventually got used to the Modular system of our project so much so that we did not worry about the additional modules that were present in each branched controller project.</li>
</ol>

<HR>
 

== '''Conclusion''' ==
CMPE243 gives one of the best experiences one could ever get in their academic life. The course is designed to give an insight into how the industry functions and enhances both technical and management skills. Apart from learning how to work and implement application of CAN protocol, one can get a hands-on experience with version control, unit-testing and software design. Overall it was a very great journey.

=== Project Video ===

=== Project Source Code ===

=== Advise for Future Students ===
'''GENERAL:'''
* Form your team and start the project as early as you can.
* Clearly discuss what role each individual should do and ensure that progress is regularly tracked so that the team doesn't fall back on any schedule.
* Since lot of code and hardware integration is involved with this project, make sure testing is thoroughly and periodically done and make note of all the issues found.
'''HARDWARE:'''
* Decide on how you would power up the peripherals. We had issues with Bluetooth (not connecting), GPS (lock not happening) and LIDAR (giving incorrect values). After lot of cycles of hardware and software debugging, we found that the issue was with power. Choose wisely as to which peripherals must be connected to which power bank.
* PCB design is time consuming as there is a lot of hardware components involved and a huge responsibility falls on the designer to know the about each component. Coordinating with multiple team members and verifying with them if their respective hardware is correct takes a lot of time. So start well ahead.
* Make sure to expose some extra GPIO and GND pins for future use.
'''MOTOR:'''
*You can use the LiPo battery to power the RPM and servo motor instead of using a separate power source. Use Vout from the ESC to get 6V.
*Start the PID control calibration early on as you will need to do extensive testing to get it working.

=== Acknowledgement ===
<HR>
Firstly we would like to express our gratitude to Professor Preetpal Kang for his guidance throughout the semester and providing us with this opportunity. We would also like to thank the ISA members Vignesh Kumar Venkateshwar and Aakash Vrajlal Chitroda for being available whenever in need and guiding us to complete the project.

== '''References''' ==

===Motor Controller===
===Geological Controller===
* Movable Scripts: [https://www.movable-type.co.uk/scripts/latlong.html Calculate distance, bearing and more between Latitude/Longitude points]
* CMPS11:[https://www.robot-electronics.co.uk/htm/cmps11i2c.htm I2C Configuration]

===Bridge and Sensor Controller===
===Driver and LCD Controller===
*LCD Software: [https://4dsystems.com.au/ulcd-32ptu 4Dsystems]
===Android===
*Youtube Channel: [https://www.youtube.com/channel/UCoNZZLhPuuRteu02rh7bzsw Coding with Mitch]
*Android Developers: [https://developer.android.com/guide/topics/connectivity/bluetooth Website][https://github.com/googlearchive/android-BluetoothChat Github]
*Udemy Course: [https://www.udemy.com/course/the-complete-android-oreo-developer-course/ Complete Android Oreo Developer Course]
===PCB Design===
*EDC Tool: [https://easyeda.com/ EasyEDA]

S20: Canster Truck

2020-05-22T05:42:51Z

Proj user22: /* Software Design */

[[File:CMPE243_S20_T2_Canster_Truck_Logo.png|thumb|455px|caption|right|CAN-STER TRUCK LOGO]]

== '''Abstract''' ==
'''The Canster Truck Project is an autonomous RC car with CAN Bus interfaced controllers. The development of the RC car's subsystem modules (Interfacing of Ultrasonic Sensor, LIDAR, Bluetooth, GPS, Compass and CAN modules) was divided among six team members. The aim of the project is to develop an autonomous RC Car which can navigate from one source location to the selected destination on the app by avoiding obstacles in its path using sensors. Waypoints algorithm is used as the path finding technique.'''

 

== '''Introduction and Objectives''' ==

'''The project was divided into 7 modules:'''

* '''Bridge and Sensor Controller'''
* '''Motor Controller'''
* '''Geological Controller'''
* '''Driver and LCD Controller'''
* '''Hardware Integration'''
* '''Android Application'''
* '''Testing & Code Review'''

'''RC Car Objectives'''
'''1. Driver and LCD Controller''' - Handles algorithms for obstacle avoidance, route maneuvering, and waypoints
'''2. Geological Controller''' - Recieves coordinates from GPS and Heading from Compass for navigation
'''3. Motor Controller''' - Controls movements of the RC Car
'''4. Bridge and Sensor Controller''' - Detects surrounding objects and interfaces android application to controller via bluetooth
'''Team Objectives'''

[[File:CMPE243_S20_T2_High_Level_System_Diagram.png|thumb|center|800px| High Level System Diagram]]

 

== '''Team Members and Responsibilities''' ==

'''Gitlab Project Link''' - [https://gitlab.com/coder137/can-ster_truck '''Canster Truck''']
 

*'''Niket Naidu''' [https://www.linkedin.com/in/niket-naidu-30090a134/ LinkedIn] [https://gitlab.com/coder137 Gitlab]
** '''Geological Controller''' : Waypoint Algorithm, Haversine and Bearing Angle logic
** '''Driver and LCD Controller''' : GLCD
** '''Bridge and Sensor Controller''' : Bluetooth
** '''Testing & Code Review'''

*'''Ganesh Ram Pamadi''' [https://www.linkedin.com/in/ganeshram93/ LinkedIn] [https://gitlab.com/ganeshram2493 Gitlab]
** '''Hardware Integration'''
** '''Testing & Code Review'''
** '''Driver Controller'''
** '''Motor Controller'''

*'''Nikhil Pabbisetty''' [https://www.linkedin.com/in/nikhilpabbisetty/ LinkedIn] [https://gitlab.com/nikhilpeoria Gitlab]
** '''Bridge and Sensor Controller'''
** '''Motor Controller'''

*'''Akhil Cherukuri''' [https://www.linkedin.com/in/akhilcherukuri/ LinkedIn] [https://gitlab.com/akhilcherukuri Gitlab] [https://github.com/akhilcherukuri Github]
** '''Android Application'''
** '''Bridge and Sensor Controller'''

*'''Ashish Anant Ladage''' [https://www.linkedin.com/in/ashish-anant-ladage-7bb3a214b/ LinkedIn] [https://gitlab.com/ashishladage1 Gitlab]
** '''Driver and LCD Controller'''
** '''Hardware Integration'''
** '''Motor Controller'''

*'''Jesus De Haro De Reza''' [https://www.linkedin.com/in/jesus-de-haro-66342424/ LinkedIn] [https://gitlab.com/deharo27 Gitlab]
** '''Bridge and Sensor Controller'''
** '''Motor Controller'''

 

== '''Administrative Responsibilities''' ==
* '''Team Lead''' - [https://www.linkedin.com/in/niket-naidu-30090a134/ '''Niket Naidu''']
* '''Git Repository Manager''' - [https://www.linkedin.com/in/niket-naidu-30090a134/ '''Niket Naidu''']
* '''Bill Of Materials Manager''' - [https://www.linkedin.com/in/akhilcherukuri '''Akhil Cherukuri''']
* '''Wiki Report Manager''' - [https://www.linkedin.com/in/akhilcherukuri '''Akhil Cherukuri''']

 

== '''Schedule''' ==

{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-

! scope="row"| '''1'''
| style="text-align:center;" |'''02/11/2020'''
| style="text-align:center;" |'''02/17/2020'''
|
*'''Form teams and decide group name'''
*'''Review past projects'''
*'''Slack: Create project group and invite Preet'''
*'''GitLab: Create project groups repository'''
*'''Analysis of component required'''

|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''2'''
| style="text-align:center;" |'''02/18/2020'''
| style="text-align:center;" |'''02/24/2020'''
|
*'''Study CAN Communication'''
*'''Create Bill of Materials'''
*'''Order RC Car'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''3'''
| style="text-align:center;" |'''02/25/2020'''
| style="text-align:center;" |'''03/02/2020'''
|
*'''Setup team finance management using Splitwise application'''
*'''Complete Bill of Materials'''
*'''Order all other required components'''
*'''Wikipedia: Setup project report template'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''4'''
| style="text-align:center;" |'''03/03/2020'''
| style="text-align:center;" |'''03/09/2020'''
|
*'''Read the respective datasheets and manuals for each component'''
*'''Test each component for working conditions'''
|
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''5'''
| style="text-align:center;" |'''03/10/2020'''
| style="text-align:center;" |'''03/16/2020'''
|
*'''Assign team responsibilities and roles'''
*'''Setup team project management environment (ClickUp)'''
*'''Define CAN DBC'''
*'''Research GPS antennas and order'''
*'''Android: Environmental setup of Android Studio and enable version control'''
*'''Hardware : Decide PCB editing software (easyEDA)'''
*'''Hardware : Draft schematic for required PCB design'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''6'''
| style="text-align:center;" |'''03/17/2020'''
| style="text-align:center;" |'''03/23/2020'''
|
*'''Hardware : Create model of PCB''' 
*'''Android: Add a Button for changing bluetooth connection status in the application''' 
*'''Geological: Interface Compass module with SJ-2 board using I2C interface''' 
*'''Geological: Interface GPS module with SJ-2 board using the UART interface''' 
*'''Geological: Parse raw data to get meaningful values for GPS and Compass''' 
*'''Sensor: Interface and check the functionality of ultrasonic sensors to the SJ-2 board''' 
*'''Motor: Interface of Servo & DC motor to the SJ-2 board and check for basic functionality''' 
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''7'''
| style="text-align:center;" |'''03/24/2020'''
| style="text-align:center;" |'''03/30/2020'''
|
*'''Hardware : Finalize components placement on PCB.''' 
*'''Motor: Add PWM functionality and test the code on DC and servo motors''' 
*'''Sensor: Interface and check and study the output readings of Lidar sensor with SJ-2 board over UART''' 
*'''LCD Display: Explore UI designing of LCD''' 
*'''Hardware: Finalize on optimal ultrasonic sensor placements''' 
*'''Android: Initiate Bluetooth communication and show staus via text view''' 
*'''Wikipedia: Establish final wiki schedule'''
*'''Complete CAN communication format for each controller and link DBC file to the Wiki'''
*'''Complete high-level system block diagram'''
*'''Complete unit-level block diagrams'''
*'''Bridge: Interface HC-5 bluetooth module with Sj-2 board using serial communicaton'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''8'''
| style="text-align:center;" |'''03/31/2020'''
| style="text-align:center;" |'''04/06/2020'''
|
*'''Hardware: Analyze PCB model and order PCB Circuit board''' 
*'''Android: Initiate Bluetooth communication and send "Hello World".''' 
*'''Wikipedia: Start adding information/images/diagrams to the relevant sections'''
*'''Motor: Configure ESC for correct speed outcome according to frequency & PWM values''' 
*'''Motor: Finish RPM sensor hardware and software implementation and integration''' 
*'''Sensor: Read output from Lidar and setup structure for outputting for DBC''' 
*'''Geological: Implement waypoints algorithm''' 
*'''Driver: Implement obstacle avoidance algorithm''' 
*'''Bridge: Pass data such as "Hello World" from HC-05 bluetooth module to bluetooth terminal android application'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''9'''
| style="text-align:center;" |'''04/07/2020'''
| style="text-align:center;" |'''04/13/2020'''
|
*'''Hardware: Remove Unused parts from RC Car''' 
*'''Hardware: Mount PCB and 3D Parts''' 
*'''Motor: Decide different cut-off values from sensor to command right /slight right/ straight/ slight left/ left to motor.''' 
*'''Android: Embed Google Maps API for setting the car's destination.''' 
*'''LCD: Work to show RC cars live status information(battery level, current speed, long, lat, bearing, sensor data, etc)''' 
*'''Driver: Test obstacle avoidance algorithm and fine-tune sensor readings''' 
*'''Geological: Test checkpoint algorithm''' 
*'''Bridge: Establish two way communication between android application and bluetooth module''' 
*'''Update Bill of Materials for miscellaneous hardware'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''10'''
| style="text-align:center;" |'''04/14/2020'''
| style="text-align:center;" |'''04/20/2020'''
|
*'''Hardware: Integrate all hardware modules''' 
*'''LCD: Testing & Validation of the LCD UI and display vehicle status information''' 
*'''Android: Send car location to the app and checkpoints received to Geo module''' 
*'''Motor: Optimize PID control by accelerating/decelerating as instructed by Driver''' 
*'''Bridge: Configure HC-05 for auto reconnection if bluetooth communication disconnects''' 
*'''Add multiple debug messages and transmit on CAN'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''11'''
| style="text-align:center;" |'''04/21/2020'''
| style="text-align:center;" |'''04/27/2020'''
|
*'''Android: Send additional vehicle status information from RC car to the Application for display''' 
*'''Android: Finalize User Interface Design and Icon''' 
*'''Continuously test the whole system and handling of corner cases (outside).'''
*'''Finalize RC Car For Project Proto 1'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''12'''
| style="text-align:center;" |'''04/28/2020'''
| style="text-align:center;" |'''05/04/2020'''
|
*'''Gitlab: Push final code'''
*April 28th: Project Proto 1
*'''Finalize RC Car for Project Demo'''
*May 1st: Project Presentation
*'''Finalize RC Car for Project Proto 2'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''13'''
| style="text-align:center;" |'''05/05/2020'''
| style="text-align:center;" |'''05/21/2020'''
|
* '''Complete Individual Contribution Peer Grading'''
* '''Review and Complete Wiki Project Page'''
|
*'''Completed'''
*'''In Progress'''
|-
|}

 

== '''Bill Of Materials''' ==
{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Item#
! scope="col"| Part Description
! scope="col"| Part Model & Vendor
! scope="col"| Quantity
! scope="col"| Cost in USD
|-
! scope="row"| 1
| '''Microcontroller Boards'''
| SJ2 Boards (Purchased from Preet Kang)
| 4
| $200.00
|-
! scope="row"| 2
| '''CAN Transceivers'''
| [https://www.waveshare.com/sn65hvd230-can-board.htm Waveshare SN65HVD230]
| 12
| $54.48
|-
! scope="row"| 3
| '''RC Car'''
| [https://www.amazon.com/Traxxas-Slash-Course-2-4GHZ-Vehicle/dp/B01DU474B0/ref=sr_1_3?ie=UTF8&qid=1474747759&sr=8-3&keywords=Traxxas+1%2F10+slash+2wd Traxxas 2WD RTR with 2.4Ghz Radio]
| 1
| $260.00
|-
! scope="row"| 4
| '''Lithium-Ion Battery'''
| [https://www.rcsuperstore.com/traxxas-7600mah-2s-7-4v-25c-id-lipo-battery-pack/ Traxxas 7600mAh 2S 7.4V 25C iD LiPo Battery Pack]
| 1
| $75.00
|-
! scope="row"| 5
| '''Lithium-Ion Battery Charger'''
| [https://www.amazon.com/Traxxas-2970-EZ-Peak-Charger-Identification/dp/B00OAFYLJC/ref=pd_bxgy_21_img_2?ie=UTF8&psc=1&refRID=JVX791WVV9Y8T9DW92KW Traxxas 2970 EZ-Peak Plus 4-Amp NiMH/LiPo Fast Charger]
| 1
| $50.00
|-
! scope="row"| 6
| '''Compass Breakout Board'''
| [https://www.dfrobot.com/product-1275.html DFRobot CMPS11 Compass]
| 1
| $29.99
|-
! scope="row"| 7
| '''Bluetooth Breakout Board'''
| [https://www.amazon.com/HC-05-Bluetooth-Pass-through-Wireless-Communication/dp/B01G9KSAF6/ref=sr_1_4?ie=UTF8&qid=1507077325&sr=8-4&keywords=arduino+bluetooth+hc-05 DSD TECH Bluetooth HC-05]
| 1
| $8.49
|-
! scope="row"| 8
| '''LIDAR Sensor'''
| [https://www.amazon.com/RPLiDAR-A1M8-Degree-Laser-Scanner/dp/B07H7X3SFF/ref=sr_1_fkmrnull_1?crid=2FSUI76G4UA8K&keywords=rplidar+a1m8+-+360+degree+laser+scanner+development+kit&qid=1552764172&s=gateway&sprefix=RPlidar%2Caps%2C263&sr=8-1-fkmrnull SEEED STUDIO RPLIDAR A1M8]
| 1
| $109.99
|-
! scope="row"| 9
| '''RPM Sensor'''
| [https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM Traxxas 6520 RPM Sensor]
| 1
| $13.70
|-
! scope="row"| 10
| '''GPS Breakout Board'''
| [https://www.adafruit.com/product/746 Adafruit Ultimate GPS Breakout v3]
| 1
| $44.30
|-
! scope="row"| 11
| '''LCD Display'''
| [https://4dsystems.com.au/ulcd-32ptu 4Dsystems 3.2 TFT-LCD ULCD-32PTU]
| 1
| $79.00
|-
! scope="row"| 12
| '''Ultrasonic Sensors'''
| [https://www.amazon.com/gp/product/B01COSN7O6/ ELEGOO HC-SR04 Ultrasonic Module]
| 5
| $12.00
|-
! scope="row"| 13
| '''GPS Antenna'''
| [https://www.amazon.com/dp/B07RRT615K/ GPS Antenna A1-UX]
| 1
| $10.98
|-
! scope="row"| 14
| '''PCB Fabrication'''
| [https://jlcpcb.com/ JLCPCB]
| 5
| $40.15
|-
! scope="row"| 15
| '''Miscellaneous'''
| [https://www.amazon.com Amazon],[https://www.mouser.com/ Mouser Electronics],[https://www.digikey.com/ Digikey],[https://anchor-electronics.com/ Anchor Electronics]
| ~
| $48.07
|-
! scope="row"|
|
|
| '''Total'''
| '''$1036.15'''
|-

|}

 

== '''Printed Circuit Board''' ==

=== Design And Architecture ===
The complete PCB (for boards and hardware peripherals) was designed using EasyEDA online software. The 4 nodes will be communicating via CAN bus and other peripherals are connected to the PCB via headers.

=== Power Section===
We have 2 power banks supplying our system. And the Servo Motor, RPM sensor and DC rear Motor (via ESC) are powered using LiPo battery (6 volts).
* Power bank #1 - Subset 2

* Power bank #2 - Subset 1, Subset 3, Bluetooth

'''NOTE:'''

'''Subset 1:'''
1. LIDAR
2. LCD
3. Compass

'''Subset 2:'''
1. Motor node
2. Driver node
3. BS node

'''Subset 3:'''
1. Geo node
2. Back ultrasonic sensor

=== Fabrication ===
* PCB was sent to fabrication to JLCPCB China which provided PCB with MOQ of 5 and 2 layers of PCB with common grounded the entire copper area.
'''DRC elements'''
* Track Width = 12
* Clearance = 10
* Via Diameter = 24
* Via Drill Diameter = 12

=== Challenges ===
* Auto-routing gave lot of challenges (only ~60% success) and sometimes the online server even crashes and faces downtime. Even local routing had lot of issues. So make sure to plan your design accordingly.
* We started our PCB design well ahead of the project. So lot of pre-planning had to be done with regard to final hardware and placement of components in order to avoid spending extra time and money while re-ordering.
* The PCB went through a lot of internal revisions even before placing order. This was time-consuming.

'''Other hardware challenges:'''
* Figuring out why various hardware peripherals (GPS, Bluetooth, LIDAR and Ultrasonic sensor) started to malfunction (devices were on but values were either inconsistent / not occurring), took a lot of time to debug. It was due to insufficient power.

 

[[File:CMPE243 S20 T2 EasyEDA.png|1040x1200px|thumb|center|PCB Layout Design in EasyEDA]]
[[File:CMPE243 S20 T2 PCB SCHEMATIC.jpg|1041x550px|thumb|center|PCB Schematic]]

<div><ul>
<li style="display: inline-block;"> [[File:CMPE243 S20 T2 PCBFRONT.jpg|thumb|none|600px|PCB Top Layer]] </li>
<li style="display: inline-block;"> [[File:CMPE243 S20 T2 PCBBACK.jpg|thumb|none|600px|PCB Bottom Layer]] </li>
</ul></div>

 

== '''CAN Communication''' ==
<Talk about your message IDs or communication strategy, such as periodic transmission, MIA management, etc.>

=== Hardware Design ===
<Show your CAN bus hardware design>

=== DBC File ===

DBC FILE: [https://gitlab.com/coder137/can-ster_truck/-/blob/dbc-improvements/projects/lpc40xx_freertos/project.dbc Gitlab]

<pre>
VERSION ""

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

BS_:

BU_: DBG DRIVER IO MOTOR SENSOR GEO

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" GEO,MOTOR,SENSOR

BO_ 101 GEO_HEARTBEAT: 1 GEO
SG_ GEO_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,MOTOR,SENSOR

BO_ 102 MOTOR_HEARTBEAT: 1 MOTOR
SG_ MOTOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,SENSOR

BO_ 103 SENSOR_HEARTBEAT: 1 SENSOR
SG_ SENSOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,MOTOR

BO_ 200 MOTOR_STEERING: 1 DRIVER
SG_ MOTOR_STEERING_direction: 0|8@1- (1,0) [-2|2] "" MOTOR

BO_ 210 DRIVER_COORDINATES: 8 DRIVER
SG_ DRIVER_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
SG_ DRIVER_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 220 MOTOR_SPEED: 1 DRIVER
SG_ MOTOR_SPEED_processed: 0|8@1- (1,0) [-3|3] "" MOTOR

BO_ 300 GEO_DEGREE: 8 GEO
SG_ GEO_DEGREE_current: 0|32@1+ (0.000001,0) [0|360] "degrees" DRIVER
SG_ GEO_DEGREE_required: 32|32@1+ (0.000001,0) [0|360] "degrees" DRIVER

BO_ 310 GEO_DESTINATION_REACHED: 1 GEO
SG_ GEO_DESTINATION_REACHED_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 400 MOTOR_SPEED_FEEDBACK: 4 MOTOR
SG_ MOTOR_SPEED_current: 0|32@1+ (0.1,0) [0|60] "kph" DRIVER

BO_ 500 SENSOR_BT_COORDINATES: 8 SENSOR
SG_ SENSOR_BT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
SG_ SENSOR_BT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 510 SENSOR_SONARS: 8 SENSOR
SG_ SENSOR_SONARS_left: 0|21@1+ (0.001,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right: 21|21@1+ (0.001,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle: 42|21@1+ (0.001,0) [0|0] "cm" DRIVER

BO_ 520 SENSOR_LIDAR: 8 SENSOR
SG_ SENSOR_LIDAR_middle: 0|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_slight_left: 16|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_slight_right: 32|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_back: 48|16@1+ (1,0) [0|0] "cm" DRIVER

BO_ 530 MOTOR_KEY: 1 SENSOR
SG_ MOTOR_KEY_val: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 900 GEO_CURRENT_COORDINATES: 8 GEO
SG_ GEO_CURRENT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" DBG
SG_ GEO_CURRENT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" DBG

BO_ 901 GEO_DISTANCE_FROM_DESTINATION: 4 GEO
SG_ GEO_distance_from_destination: 0|32@1+ (0.001,0) [0|0] "meters" DBG

BO_ 902 MOTOR_INFO_DBG: 4 MOTOR
SG_ MOTOR_INFO_DBG_rps: 0|16@1+ (1,0) [0|0] "" DBG
SG_ MOTOR_INFO_DBG_pwm: 16|16@1+ (0.001,0) [0|0] "" DBG

BO_ 903 LIPO_BATTERY_VOLTAGE_DBG: 4 MOTOR
SG_ LIPO_BATTERY_VOLTAGE_val: 0|32@1+ (0.01,0) [0|0] "volts" DBG

BO_ 904 CURRENT_CHECKPOINT_DBG: 1 GEO
SG_ CURRENT_CHECKPOINT_val: 0|8@1+ (1,0) [0|0] "" DBG

CM_ "--BU (Network Node) Information--";
CM_ BU_ DRIVER "The driver controller of the car";
CM_ BU_ GEO "The geo controller of the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";

CM_ "--BO (Message) Information--";
CM_ BO_ 100 "Driver Sync message used to synchronize the controllers";
CM_ BO_ 101 "Geo Sync message used to synchronize the controllers";
CM_ BO_ 102 "Motor Sync message used to synchronize the controllers";
CM_ BO_ 103 "Sensor Sync message used to synchronize the controllers";

CM_ BO_ 200 "Steering direction values sent by Driver Node to Motor Node";
CM_ BO_ 210 "Driver Destination coordinates sent by Driver Node";
CM_ BO_ 220 "Required motor speed computed from Driver Node to Motor Node";

CM_ BO_ 300 "Current and computer/required degree values sent by Geo Node";
CM_ BO_ 310 "Indicator signal to check if the RC car has reached the destination";

CM_ BO_ 400 "Current motor info (rps and kph) sent as feedback to the Driver Node";

CM_ BO_ 500 "Coordinate BT values (destination coordinates) sent by Sensor Node";
CM_ BO_ 510 "LIDAR - Distance from obstacle detected in each sector";
CM_ BO_ 520 "Ultrasonic Sensor - Distance from obstacle detected by each sensor";
CM_ BO_ 530 "Start/Stop signal from the Bluetooth app";

CM_ BO_ 900 "Destination coordinates for BUSMASTER debugging";
CM_ BO_ 901 "Distance from destination";
CM_ BO_ 902 "Supplied PWM value to the motor and its RPM";
CM_ BO_ 903 "LIPO Battery Voltage";
CM_ BO_ 904 "Current checkpoint of the car";

CM_ "--SG (Signal) Information for Heartbeats--";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver node";
CM_ SG_ 101 GEO_HEARTBEAT_cmd "Heartbeat command from the geological node";
CM_ SG_ 102 MOTOR_HEARTBEAT_cmd "Heartbeat command from the motor node";
CM_ SG_ 103 SENSOR_HEARTBEAT_cmd "Heartbeat command from the sensor node";

CM_ "--SG (Signal) Information for DRIVER Node--";
CM_ SG_ 200 DRIVER_STEERING_direction "Calculated Driver Steering values (-2,2) for Motor";
CM_ SG_ 210 DRIVER_COORDINATES_latitude "Destination Latitude coordinate";
CM_ SG_ 210 DRIVER_COORDINATES_longitude "Destination Longitude coordinate";
CM_ SG_ 220 MOTOR_SPEED "Calculated Driver speed values (-3,3) for Motor";

CM_ "--SG (Signal) Information for GEO Node--";
CM_ SG_ 300 GEO_DEGREE_current "Current Geo Degree relative to true north";
CM_ SG_ 300 GEO_DEGREE_required "Calculated Geo Degree computed by Haversine Formula";
CM_ SG_ 310 GEO_DESTINATION_REACHED "Indicator signal to check if the RC car has reached the destination";

CM_ "--SG (Signal) Information for MOTOR Node--";
CM_ SG_ 400 MOTOR_SPEED_FEEDBACK "Feedback speed (kph) sent by Motor Node";

CM_ "--SG (Signal) Information for SENSOR Node--";
CM_ SG_ 500 SENSOR_BT_COORDINATES_latitude "Destination Latitude received over Bluetooth";
CM_ SG_ 500 SENSOR_BT_COORDINATES_longitude "Destination Longitude received over Bluetooth";
CM_ SG_ 510 SENSOR_SONARS_left "Ultrasonic Sensor attached to the left side";
CM_ SG_ 510 SENSOR_SONARS_right "Ultrasonic Sensor attached to the right side";
CM_ SG_ 510 SENSOR_SONARS_middle "Ultrasonic Sensor attached to the middle";
CM_ SG_ 510 SENSOR_SONARS_back_left "Ultrasonic Sensor attached to the back left side";
CM_ SG_ 510 SENSOR_SONARS_back_right "Ultrasonic Sensor attached to the back right side";
CM_ SG_ 520 SENSOR_LIDAR_middle "Lidar sensing the middle sector (-15 to 15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_left "Lidar sensing the slight left sector (-45 to -15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_right "Lidar sensing the slight right sector (15 to 45 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_back "Lidar sensing the back of the car (165 to 195 degrees)";
CM_ SG_ 530 MOTOR_KEY_val "1 -> Start the motor from the app, 0 -> Stop";

CM_ SG_ 900 GEO_CURRENT_COORDINATES_latitude "Current Latitude";
CM_ SG_ 900 GEO_CURRENT_COORDINATES_longitude "Current Longitude";
CM_ SG_ 901 GEO_distance_from_destination "Distance from destination";
CM_ SG_ 902 MOTOR_INFO_DBG_rps "Current RPS value of the motor";
CM_ SG_ 902 MOTOR_INFO_DBG_pwm "Supplied motor PWM value";
CM_ SG_ 903 LIPO_BATTERY_VOLTAGE_val "LIPO Battery Voltage";
CM_ SG_ 904 CURRENT_CHECKPOINT_val "Current checkpoint of the car";

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

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

BA_ "GenMsgCycleTime" BO_ 100 1000;
BA_ "GenMsgCycleTime" BO_ 200 50;
BA_ "FieldType" SG_ 100 DRIVER_HEARTBEAT_cmd "DRIVER_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 102 GEO_HEARTBEAT_cmd "GEO_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 103 MOTOR_HEARTBEAT_cmd "MOTOR_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 104 SENSOR_HEARTBEAT_cmd "SENSOR_HEARTBEAT_cmd";

BA_ "FieldType" SG_ 200 MOTOR_STEERING "MOTOR_STEERING";
BA_ "FieldType" SG_ 230 MOTOR_SPEED_val "MOTOR_SPEED_val";
BA_ "FieldType" SG_ 310 GEO_DESTINATION_REACHED_cmd "GEO_DESTINATION_REACHED_cmd";

VAL_ 100 DRIVER_HEARTBEAT_cmd 2 "DRIVER_HEARTBEAT_cmd_REBOOT" 1 "DRIVER_HEARTBEAT_cmd_SYNC" 0 "DRIVER_HEARTBEAT_cmd_NOOP" ;
VAL_ 101 GEO_HEARTBEAT_cmd 2 "GEO_HEARTBEAT_cmd_REBOOT" 1 "GEO_HEARTBEAT_cmd_SYNC" 0 "GEO_HEARTBEAT_cmd_NOOP";
VAL_ 102 MOTOR_HEARTBEAT_cmd 20 "MOTOR_HEARTBEAT_cmd_REBOOT" 10 "MOTOR_HEARTBEAT_cmd_SYNC" 0 "MOTOR_HEARTBEAT_cmd_NOOP" ;
VAL_ 103 SENSOR_HEARTBEAT_cmd 200 "SENSOR_HEARTBEAT_cmd_REBOOT" 100 "SENSOR_HEARTBEAT_cmd_SYNC" 0 "SENSOR_HEARTBEAT_cmd_NOOP" ;

VAL_ 200 MOTOR_STEERING_direction -2 "MOTOR_STEERING_hard_left" -1 "MOTOR_STEERING_slight_left" 0 "MOTOR_STEERING_straight" 1 "MOTOR_STEERING_slight_right" 2 "MOTOR_STEERING_hard_right";
VAL_ 220 MOTOR_SPEED_processed -3 "MOTOR_SPEED_reverse_fast" -2 "MOTOR_SPEED_reverse_medium" -1 "MOTOR_SPEED_reverse_slow" 0 "MOTOR_SPEED_neutral" 1 "MOTOR_SPEED_forward_slow" 2 "MOTOR_SPEED_forward_medium" 3 "MOTOR_SPEED_forward_fast";
VAL_ 310 GEO_DESTINATION_REACHED_cmd 1 "GEO_DESTINATION_REACHED_cmd_REACHED" 0 "GEO_DESTINATION_REACHED_cmd_NOT_REACHED";
</pre>

 

== '''Motor Controller''' ==
<Picture and link to Gitlab>

This controller is used to control the components of the car-related to motor. We can control the speed and steering of the car having interfaced with various components with the SJ-2 board. The servo motor is controlled via PWM and is used to set the steering direction of the car. The DC motor is controlled by the Electronic Speed Controller (ESC) via PWM for speed. We read the speed of the car by using an RPM sensor. By using the RPM sensor values, a feedback loop has been designed to regulate the speed of the car. A state machine has been designed to manage the forward and backward movements of the car.
Additionally, a voltage divider circuit has been implemented to read the battery voltage. All motor functionality and CAN message communication is run at 10 Hz.

=== Hardware Design ===

The following diagram details the hardware implementation of the motor module with the SJTwo board:
Hardware Interface
- Servo Motor
The servo motor responds to PWM pulses. It has three pins namely Vcc, PWM Input Signal, and GND. The servo is powered using 6V from the car battery. Based on the PWM signal supplied from the SJTwo board the front wheels are turned.
- Electronic Speed Controller (ESC)
The ESC is used to control the DC motor. It is supplied power using the 7.4 V LiPo battery. It has three pins namely Vout, PWM Input Signal, and GND. Based on the PWM input signal, the speed and forward, neutral, and backward movements of the car is changed. Vout is given to the RPM sensor and Servo motor.
- DC Motor
The DC motor is controlled using the ESC. It has two pins, a positive and negative terminal. A PWM signal wire is connected to the microcontroller and the required current is provided by the LiPo battery and the ESC. The DC motor is controlled using PWM at 10Hz.

[[File:CMPE243_S20_T2_Canster_Truck_Motor_Hardware.png|thumb|center|750px| Motor Hardware System]]

Note: First calibrate the DC motor or the motor will not respond to your PWM pulses. For help with calibration go to this [https://traxxas.com/support/Programming-Your-Traxxas-Electronic-Speed-Control website]

- RPM Sensor

The RPM sensor is used to get the current speed of the car. We use the info for creating a feedback loop (PID) for maintaining the speed of the car in uphill and downhill situations. The RPM sensor mounts on the rear DC motor shaft compartment with a special assembly also provided by Traxxas. The magnet which attached to the inner gear generates a pulse each rotation. The sensor works on the hall effect principle where it provides a current across its terminal when placed in a magnet's field. The RPM sensor has three pins namely Vcc, Signal, and GND.

- Battery Voltage Divider Circuit
- (Need Niket’s help)

=== Software Design ===

The software for the motor node was divided into multiple files and made modular to improve readability and understanding of the complex logic involved. The main code modules are for:
• Servo Motor
• Electronic Speed Controller
• RPM Sensor
• Motor Wrapper
• Battery Voltage

The motor wrapper module is used to wrap all the code from the esc, servo, and rpm modules into simple to use functions to be called in the periodic tasks.
• Servo Motor
It uses the steering value sent from the driver (-2 to 2) and matches it to the appropriate PWM value for steering. This code module is run at 10Hz.
<pre>
void servo__steer_processor(int16_t steering_value) {
switch (steering_value) {
case MOTOR_STEERING_hard_left:
servo__steer_hard_left();
break;
case MOTOR_STEERING_slight_left:
servo__steer_soft_left();
break;
case MOTOR_STEERING_straight:
servo__steer_straight();
break;
case MOTOR_STEERING_slight_right:
servo__steer_soft_right();
break;
case MOTOR_STEERING_hard_right:
servo__steer_hard_right();
break;
default:
printf("\nDid not receive steering value");
}
}
</pre>
• Electronic Speed Controller

This code module is used to control the DC motor. It receives the motor direction value from the driver and sets the appropriate PWM value. Based on the value the motor is commanded to move the car forward or backwards. A switch case is implemented to set PWM values for movement in different directions along with different speeds.
<pre>
void esc__direction_processor(int16_t direction_value) {
desired_direction_value = direction_value;
switch (direction_value) {
case MOTOR_SPEED_reverse_fast:
esc__reverse_fast();
break;
case MOTOR_SPEED_reverse_medium:
esc__reverse_medium();
break;
case MOTOR_SPEED_reverse_slow:
esc__reverse_slow();
break;
case MOTOR_SPEED_neutral:
esc__neutral();
break;
case MOTOR_SPEED_forward_slow:
esc__forward_slow();
break;
case MOTOR_SPEED_forward_medium:
esc__forward_medium();
break;
case MOTOR_SPEED_forward_fast:
esc__forward_fast();
break;

default:
printf("\nDid not receive direction and speed value");
}
}
</pre>

There is also a feedback loop to control the speed. The ESC code depends on the rpm sensor code for the current speed values.
<pre>
double current_speed = get_speed_kph();
double desired_speed = desired_speed_kph;
float adjusted_duty_cycle = 0.0;
adjusted_duty_cycle = duty_cycle + (speed_to_pwm_adjustment(desired_speed, current_speed));
</pre>

[[File:CMPE243_S20_T2_Canster_Truck_Motor1.png|thumb|center|400px| Motor Flowchart 1]]

• RPM Sensor
This code module is used to get current speed data from the RPM sensor. It is based on interrupts. When the wheel rotates once, we get one pulse due to the magnet installed. This pulse generates a falling edge interrupt during which we increment the pulse counter. Since, this code is run at 1Hz we collect the number of pulses generated every one second. This gives us the number of rotations per second using which we can calculate the speed in kph.
<pre>
float rpm__calculate_speed_kph() {
uint16_t rotation_per_sec = pulse_count;
pulse_count = 0;
speed_kph = ((CIRCUMFERENCE_METER * rotation_per_sec) * (MPS_TO_KPH_CONVERSION_FACTOR)) / GEAR_RATIO;
return speed_kph;
}
</pre>

• Motor Wrapper
As mentioned above, the main function of this code module is to wrap all the other code modules and call the right functions at the appropriate frequency. The motor wrapper code also includes a state machine for ensuring a smooth transition between forward to backward state and vice versa. In order to achieve a smooth transition, a series of PWM pulses must be generated at the right time. For example, when the motor is moving from forward to backward state, a reverse value must be given first followed by at least three neutral values, and then continue with reverse values.

[[File:CMPE243_S20_T2_Canster_Truck_Motor2.png|thumb|center|400px| Motor Flowchart 2]]

=====LIPO Battery Voltage=====
The LIPO Battery Voltage was calculated using ADC in Burst Mode. A LIPO Hardware module was created for the same which contained two functions, <code>lipo__init</code> and <code>lipo__get_voltage</code>.

The voltage divider circuit is stepped down from 7.4V to 2.1V using 10K and 4K Resistor pair.

'''LIPO Initialization'''

The LIPO Initialization phase initializes the ADC, Enables Burst mode on the ADC pins and configures the Alternate Function Registers for the same.

'''LIPO Get Voltage'''

We read the raw ADC value from the LPC Hardware register. This value will be from 0 - 3.3V. However due to our voltage divider configuration the max voltage that we should theoretically get is 2.1V. This means that 2.1V corresponds to 7.4V of the LIPO Battery voltage.

The formula used is
<code>(raw_adc_value * MAX_LIPO_BATTERY_VOLTAGE_VALUE) / MAX_LIPO_ADC_VALUE</code>

=== Technical Challenges ===
<ol>
<li>Changing movements of the car from Forward to Backward and vice versa
If you just change the PWM value from say 16 (Forward) to 14(Backward), the DC motor will just stop and will not make wheels turn reverse. We discovered this problem quite late as during the initial testing we had always run the car from the start with either forward or reverse but never tried changing the direction during run-time.
Solution: The motor requires a series of PWM pulses which is specific to the car to transition from forward mode to reverse mode. In our case we had to give the PWM pulses in the following sequence. Suppose,
<ol>
<li> Forward (16) (callback_count=0)</li>
<li> Forward (16) (callback_count =1)</li>
<li> Reverse (14) (callback_count =2)</li>
<li> Neutral (15) (callback_count = 3)</li>
<li> Neutral (15) (callback_count = 4)</li>
<li> Neutral (15) (callback_count = 5)</li>
<li> Reverse (14) (callback_count = 6)</li>
<li> Continue reverse</li>
</ol>
Similarly, the reverse to forward can also be implemented.
<li>DC motor shooting off when there is an improper ground connection
When we connected the battery voltage circuit for reading the voltage from the battery, the motor would randomly shoot off every now and then.
Solution: Connect the voltage divider circuit to the common ground rather than taking the ground from the ESC.</li>
</ol>

<HR>
 

== '''Geological Controller''' ==

<Picture and link to Gitlab>

===Messages===
*GEO_HEARTBEAT: Used to check for MIA by other nodes. Highest priority message for GEO Node

*GEO_DEGREE: Sends the current degree relative to the North Pole computed by the Compass and the Required degree relative to the North Pole computed by Bearing Angle using the Current Coordinate and Destination Coordinate.

*GEO_DESTINATION_REACHED: Sets a flag, 0 for destination not reached and 1 for destination reached

*GEO_CURRENT_COORDINATES: Debug Message used to send the Current GPS Coordinates

*GEO_DISTANCE_FROM_DESTINATION: Debug message used to send the Distance from Destination

*CURRENT_CHECKPOINT_DBG: Debug message used to check which checkpoint is being navigated to

=== Hardware Design ===

[[File:CMPE243_S20_T2_GEO1.png|thumb|center|650px| Geological Diagram]]

=== Software Design ===
=====Overview=====
*Inside the `periodic_callback__initialize`
**Initialize the CAN BUS
**Initialize the GPS

*Inside the `periodic_callback__1hz`
**Handle all MIA (from other Nodes)
**Update GPS LED when init and in case of failure
**Compute the GEOLOGIC for Waypoints algorithm once every second (1000 ms)

*Inside the `periodic_callback__10hz`
**Handle CAN Incoming messages (Decode)
**Transmit CAN Geo messages (Encode and send)
**Compute the GPS Coordinate

=====Compass I2C Driver=====
An online datasheet resource was used to work with the Compass (https://www.robot-electronics.co.uk/htm/cmps11i2c.htm)
Initially the Compass I2C Driver was tested using the Terminal I2C Helper built by our Professor Preetpal Kang. Using this resource we were quickly able to read various I2C Registers and display it onto the terminal.

For our project the only required part of the Compass was the 16-bit Compass Bearing value (0-3599) i.e 0-359.9 degree values. These values were stored in the 2nd and 3rd register (Register 2 being the High Byte).
Once the raw data was received over I2C we could easily combine the data

<pre>
uint16_t bearing_value = (Reg2 << 8) | Reg3;
float rval = bearing_value / 10.0;
return rval;
</pre>
The returned value were transmitted to the Driver Node to compute its steering based on the required Bearing Angle.

=====GPS Initialization=====
GPS Initialization activates the Hardware GPIO (RX and TX), FreeRTOS Queue for UART Interrupts (UART Module) and Line Buffer Module to parse each GPS line.

=====GPS Data Parsing=====
The GPS Hardware module transmits an NMEA string over UART to the SJTwo Board. We read each character one by one and add it to the Line Buffer module.
Inside its computation loop, the Line Buffer module checks if a newline character has been received.
When a newline character has been received the entire string is extracted from the line buffer module and parsed according to its identifier ($GPRMC, $GPGGA) received and parsed into individual tokens.
For our purposes the $GPRMC NMEA string was the most appropriate and it helped us extract the Current Latitude Longitude as well as the Valid/Invalid tag for the Canster Truck.

=====GPS LED Indication for debugging=====

A simple module that checks for the GPRMC GPS Message and extracts the A or V valid (Tag). If $GPRMC NMEA string is valid, LED is set, else LED is reset. This gives us onsite debugging capabilities to know if GPS has locked onto a satellite signal.

=====GEO Logic Module Computation=====
The GEO Logic Module computes the Bearing Angle, Haversine Distance as well as the Waypoints algorithm.

'''Bearing Angle:'''

<code>
θ = atan2( sin Δλ ⋅ cos φ2 , cos φ1 ⋅ sin φ2 − sin φ1 ⋅ cos φ2 ⋅ cos Δλ )
</code>

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

Since atan2 returns values in the range -π ... +π (that is, -180° ... +180°), to normalize the result to a compass bearing (in the range 0° ... 360°, with −ve values transformed into the range 180° ... 360°), convert to degrees and then use (θ+360) % 360, where % is (floating point) modulo.
For final bearing, simply take the initial bearing from the endpoint to the start point and reverse it (using θ = (θ+180) % 360).

The above article reference gives us the required bearing angle that our car must align itself to, to reach a particular destination coordinate from its current coordinate.
The Steering of the Canster Truck depends on the above-computed angle values.

'''Haversine Distance Formula:'''

This uses the ‘haversine’ formula to calculate the great-circle distance between two points – that is, the shortest distance over the earth’s surface – giving an ‘as-the-crow-flies’ distance between the points (ignoring any hills they fly over, of course!).

<code>
a = sin²(Δφ/2) + cos φ1 ⋅ cos φ2 ⋅ sin²(Δλ/2)

c = 2 ⋅ atan2( √a, √(1−a) )

d = R ⋅ c
</code>

where φ is latitude, λ is longitude, R is earth’s radius (mean radius = 6,371km);
note that angles need to be in radians to pass to trig functions!

The above formula is used to calculate the distance between the source coordinate (received via GPS) and the destination coordinate.
Later this was used to compute the distance between source coordinate and each individual checkpoint to traverse the shortest distance.

'''Waypoints Algorithm:'''

The Waypoints algorithm that was chosen was a slightly modified version of Djikstra’s Algorithm.
3 values were calculated before the final computation
- Distance between source and final destination (DISTsd)
- Distance between source and each individual checkpoint (DISTsc)
- Distance between each individual checkpoint and the final destination. (DISTcd)
If DISTsd was lesser than DISTcd, this checkpoint was discarded (we continue in the loop). Since we would be moving in the opposite direction, rather than towards the final destination.
If DISTsd was greater than DISTcd, then we checked the nearest checkpoint to the source.
The minimum value was set initial that was equal to DISTsd.
If DISTsc was lesser than the minimum value stored, DISTsc would become the new minimum value, and the checkpoint index and coordinates would be appropriately stored and returned from the function.
In this way we would navigate to the nearest checkpoint from the source, while also making sure NOT to travel in the opposite direction.
This logic is recomputed only when we reach the checkpoint selected and the algorithm runs again to find the next checkpoint that we need to navigate to.

=====CAN Decode Destination Coordinates=====
Destination Coordinates are received from the Bridge and Sensor Node and transmitted over the CAN Bus. The value is decoded and stored in the GEO Logic Module.
This is a very important value since our entire GEO Logic calculations are based on the Destination Coordinate.

=====CAN Encode and Send=====

The main messages that were transmitter are
#Geo Degree
#Geo Destination Reached
#Distance from Destination Debug and Checkpoint Index debug

'''Geo Degree Computation as per Waypoints Algorithm:'''

Geo Degree was computed as per the current coordinates and the most recently computed checkpoint coordinates. This bearing angle calculation w.r.t computed checkpoint would continue till we do not reach that particular checkpoint.
Once we reach the computed checkpoint, Waypoint algorithm is recomputed as per the process mentioned above and the algorithm runs again.

'''Geo Destination Reached:'''

An Area of around 4 meters was set around the destination coordinate to check if the destination had been reached.
This measurement was taken into consideration to allow for the loss in precision when transmitting data over CAN as well as any irregularities that might occur when getting values from the GPS.
Having an area of 4 meters was very accurate for all of our test runs.

'''Geo Distance from Destination Debug and Checkpoint Index Debug:'''

Getting debug information was very critical to speed up our development process. In this case we could actively see if our algorithm worked properly.
The Geo Distance from Destination was used to see if we were moving closer to our destination or veering further away from it.
The Checkpoint Index was used to see which checkpoint index we were traveling to. By knowing the placements of the Individual checkpoints we could manually as well as programmatically (via Android application) verify the working of our Canster Truck.

=== Technical Challenges ===
#DBC Challenge for GEO Coordinates -> Could not encode more than 5-6 decimal places at a time, on later investigation we found that the 10000 is an int value, however 100000 overflows the int value.
#Creating an efficient algorithm for Waypoints, O(n) complexity.
#Getting appropriate fixes for GPS when not in a completely open space.
#GPS used to fluctuate or stop giving values when Battery voltage went below a particular threshold. Always supply 3.3V constantly at a good amperage.

<HR>
 

== '''Sensor [Bridge and Sensor Controller]''' ==
<Picture and link to Gitlab>

==='''Ultrasonic Sensor'''===
====Hardware Design====
This sensor uses an ultrasonic beam to measure the distances. Based on the time taken between when the beam is sent and received back to the sensor, the distance is calculated in the node.
Apart from 5v and GND, this sensor has 2 pins ECHO and TRIG which are interfaced with the SJ-Two board via GPIO.

[[File:CMPE243_S20_T2_CansterTruck_ultrasonic_sensor.jpg|thumb|center|300px| Ultrasonic Sensor Diagram]]

====Software Design====
* Init the GPIO pin connected to TRIG of the sensor as output and for ECHO as an input port.
* Attach the interrupt on the ECHO input port.
* Store the system_clock_count before setting the trigger pulse and then set the pulse. Also keep monitoring the input port.
* Take the system_clock_count at the instant of receiving the interrupt.
Distance = (system_clock_count_at_trig - system_clock_count_after_at_echo) / 57.14

==='''Lidar Sensor'''===
====Hardware Design====
The RPLidar sensor can be powered from a 5-volt source and uses UART communication to receive commands and transmit data. It has seven pins to interface with. Two sets of the pins (four total) are for power and ground. The remaining three are for UART receive and transmit, and for making the lidar’s motor spin.

[[File:CMPE243_S20_T2_Canster_Truck_RPLidar_A1.JPG|thumb|center|300px| RPLidar A1]]

====Software Design====
In terms of the lidar, the SJ2 initializes GPIO, UART, and memory for storing the measurement values. After initialization, the command to begin scanning is sent. Here, we wait for the lidar to send a response packet, letting the host (SJ2 board) know it received the command. The response packet the lidar sends will be 7 bytes. If the correct 7 bytes are not received, the command will be sent again.

[[File:CMPE243_S20_T2_Canster Truck_Lidar_flow.jpeg|thumb|center|200px| Lidar Flow]]

Following the response packet, the lidar begins sending 5-byte measurement data. Each sample contains a distance measurement (in millimeters) and the angle (with respect to the lidar) in which it was taken. The data packet structure is shown in the following figure. In addition to containing the distance and angle, the packet includes a quality value, to indicate the reliability of the measurement, and three check bits (S, ~S, and C). As the data is received via UART, we wait until we have 5 bytes before continuing to process. Before processing the 5 bytes after receiving them, the check bits are confirmed to be correct. If they are incorrect, it will not be processed and we will wait for another sample to be received.

[[File:CMPE243_S20_T2_Canster Truck_DataPacketStructure.JPG|thumb|center|200px| Data Packet Structure]]

In the case the sample is correct, each measurement value that is in a direction of interest will be placed in an array designated to one of four directions (left, right, front, rear). Each of these directions have their own sector in the lidar’s 360-degree view.
*Right sector: 11°-30°
*Rear sector: 170°-190°
*Left sector: 330°-349°
*Front sector: 350°-370° (or 10°)

The arrays mentioned will hold roughly 20 measurements, which are every degree in the sector. In the event, objects are too far to measure, the lidar will report 0 mm. distance. Since there is no measurable obstacle, a “large” distance value of 3000 mm. is placed in the array. The smallest distance value will be taken from each array and reported to the driver node for obstacle avoidance.

=== Technical Challenges ===
====Ultrasonic====
====Lidar====
*'''Datasheet not 100% clear:''' The correct datasheet for the was a bit difficult to obtain, and the manufacturer needed to be contacted. The first document found online was high level and general information about the sensor, but the manufacturer did provide another document that contained the information of the commands and responses to and from the lidar, and their packet structure. The documents did not clearly state the angles with respect to the lidar are fixed, which left me wondering if the lidar will think the direction it is facing when powered on will become the new “zeroth” angle.

*'''UART Buffer Overflow:''' When first interfacing with the sensor, the incoming bytes of the lidar were printed on to the terminal to make sure there was a response and to make sense of the information. Since the command we sent results in 5 bytes of data per measurement samples from the lidar and the lidar measured 2000 times per second, there are will be roughly 10k Bytes per second of data incoming that need to be handled continuously. With an improperly sized UART buffer and print statements it is guaranteed to occur, making the lidar data look like random values.

*'''Proper Parsing of Measurement Data:''' After sending a command to the lidar, the sensor will send a response packet, followed by the measurement data. The initial response from the lidar is a 7-byte packet, followed by continuous 5-byte measurement samples. I needed to make sure however I handled the response would be independent of how the measurement is handled, so as not to create a potential unwanted offset when receiving measurements.

*'''Object Detection with Received Data:''' Once proper communication was set up with the lidar and measurement data was getting decoded, there needed to be a way to measure when obstacles were present. If ~360 measurements are handled entirely independently from one another, it could become a complex and confusing code. To achieve a simple approach, four sectors about 20 degrees in size were used to represent the front, left, right, and rear directions.

*'''Bugs in Code:''' When first implementing the code, there were a few bugs from typos, incorrect numbers, and some faulty logic that were found with the use of unit testing. Unit testing helped find these issues and verified the logic was correct, and I would say gave me 90% confidence in my lidar handling.

<HR>
 

== '''Bridge [Bridge and Sensor Controller]'''==
<Picture and link to Gitlab>

Bridge functionality of the Bridge and Sensor Controller is to establish wireless communication between the SJ-2 Board and the android mobile device using the HC-05 Bluetooth module. The Bridge controller will be receiving start command with destination GEO coordinates and stop command. The Bridge controller will be transmitting the required sensor data and debug information to be displayed on the android application.

[[File:CMPE243_S20_T2_BRIDGE.png|thumb|center|500px| Bridge Diagram]]

===Bluetooth===

==== Software Design ====
<ol>
<li> Low-Level Layer
In this layer, similar to the GPS the UART GPIO was initialized (RX, TX), FreeRTOS Queue was initialized for UART Interrupts and the line buffer module was initialized to parse strings.

Two basic functions <code>bt__read</code> and <code>bt__write</code> were implemented.
As the name suggested, <code>bt__write</code> took a string as its input parameter and transmitted that data to the Android application. <code>bt__read</code> stored the incoming characters into the line buffer, parsed the line received into its identifier and tokens, and invoked a callback function.

Since this was a low-level layer the User would not be directly invoking this library. Instead a '''Bluetooth Wrapper''' module was created which would be invoked and used by the user.
</li>

<li>Application Layer

The Bluetooth Wrapper module had the appropriate <code>read_once</code> and <code>write_once</code> functions.

The <code>read_once</code> function internally just called the <code>bt__read</code> function. All of the decodings was done inside the Callback Function.
To get the Destination coordinate the string received from the Android Application was in the form of
<code>$loc,<destination_latitude>,<destination_longitude>.</code>
Upon receiving this data we parsed the destination_latitude and destination_longitude, which could later be accessed using getters.
We also set a start flag to notify the Driver Node that destination has been received and we can start steering towards our checkpoints.

Another command implemented was the stop command.
<code>$stop</code>
This was used to send a stop flag to the Driver node.

The <code>write_once</code> function used the getter methods from each CAN Decode message and update its internal state variables. A CSV String was created using the <code>$canster</code> identifier and various debugging points were appended to this message using a comma.
On the Android application side this CSV string was tokenized and displayed onto the Application Debug screen appropriately.
</li>
</ol>

==== Technical Challenges ====

<List of problems and their detailed resolutions>

<HR>
 

== '''Driver [Driver and LCD Controller]''' ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===

[[File:CMPE243_S20_T2_Canster Truck_Driver_Flowchart.png|thumb|center|750px|Driver Flowchart]]

The above block diagram explains the process flow of obstacle detection for the car. The LIDAR detects
the obstacle and depending on the distance of obstacle the car takes a slight right and slight left or a
hard right and hard left. The state of the car also depends on the value of the LIDAR and ultrasonic sensor.
The loose ends of the LIDAR for the reverse condition are checked by the ultrasonic sensors. The
The ultrasonic sensor works on the principle of trigger and echo and can detect the obstacles very close by.
The range of the Ultrasonic sensor is lower than the LIDAR. Finally, if no obstacle is detected the car goes
straight until the destination is reached. The speed of the car is also various when an obstacle is detected to
avoid the crash and the car’s smooth transition from one state to another. The key to the android
application controls the start and stop the process of the car. If the key is not pressed, then the stays in the

neutral state. The speed of the car is controlled by the changing duty cycle of the input voltage. There
are seven-speed levels in which the motor can run on. These speed levels are Forward Slow, Medium,
Fast, Reverse Slow, Medium, Fast, and Neutral. The Neutral is the stop condition with a 0% duty cycle.

=== Technical Challenges ===

< List of problems and their detailed resolutions>

<HR>
 

== '''LCD [Driver and LCD Controller]''' ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
The GLCD used was created by 4DSystems, using their IDE a UI was created. Each UI component could be controlled by sending UART data targeted at the widget address.
The best part about this GLCD was that we had a lot of interactive widgets to display debugging information in real-time.
The GLCD code was divided into 3 parts:
<ol>
<li>'''Low-Level Initialization'''
Initialize the low-level hardware interfaces to send and receive data from the GLCD.
Similar to the GPS and Bluetooth, The UART GPIO was initialized (RX, TX), FreeRTOS Queue was initialized for UART Interrupt and line buffer was used to get a stream of data for parsing.

Low-level '''read''' and '''write''' commands were used as per the working of the GLCD Module.
When Reading data pertaining to a widget on the GLCD we would need to send a particular response packet.
<pre>
void lcd__read(lcd_object_e object_id, uint8_t object_index, uint8_t *response, uint16_t *response_data) {

uint8_t checksum = READ_OBJ ^ object_id ^ object_index;
uint8_t buffer[] = {READ_OBJ, object_id, object_index, checksum};

lcd__write_data(buffer, sizeof(buffer) / sizeof(uint8_t));
lcd__read_response_id(response);
lcd__read_response_data(response_data);
}
</pre>

The response_data returned contains the Widget ID as well as the current value stored on that widget.

When Writing data pertaining to a widget on a GLCD the process is similar to the above mentioned code.
<pre>
void lcd__write(lcd_object_e object_id, uint8_t object_index, uint8_t msb, uint8_t lsb, uint8_t *response) {
uint8_t checksum = WRITE_OBJ ^ object_id ^ object_index ^ msb ^ lsb;
uint8_t buffer[] = {WRITE_OBJ, object_id, object_index, msb, lsb, checksum};

lcd__write_data(buffer, sizeof(buffer) / sizeof(uint8_t));
lcd__read_response_id(response);
}
</pre>

However in this case we receive only an ACK or NACK from the system. ACK would mean that the write to GLCD widget was successful and the widget now stored appropriate values. NACK would mean that a particular error has occurred. The errors could be regarding baud rate, incorrect bit format, incorrect index values, etc.
</li>
<li>'''GLCD Wrapper for Widgets'''
The above low-level code had generic read and write functions. However for our UI we were only using 3 Widgets. All of which had '''different Indexes''' and '''Widget IDs'''.
Therefore a very simple library was created to easily interface with those widgets
<pre>
bool lcd_wrapper__read_led(uint8_t index);
uint16_t lcd_wrapper__read_meter(uint8_t index);
uint16_t lcd_wrapper__read_leddigit(uint8_t index);

bool lcd_wrapper__write_led(uint8_t index, bool value);
bool lcd_wrapper__write_meter(uint8_t index, uint16_t value);
bool lcd_wrapper__write_leddigit(uint8_t index, uint16_t value);
</pre>

The above code is self-explanatory read and write functions for '''LED''', '''METER''', and '''LED DIGIT'''.
</li>
<li>'''GLCD UI'''
Now that we had our low level and Widget wrapper working properly, we wanted to create our Dynamic UI as well. The code would need to be robust enough to handle any UI that we create on the GLCD which could be reflected equivalently in our C Code.

<pre>
static void lcd_ui__update_ui(void) {

lcd_wrapper__write_led(LCD_LED_DRIVER_MIA_INDEX, driver_mia_led);
lcd_wrapper__write_led(LCD_LED_SENSOR_MIA_INDEX, sensor_mia_led);
lcd_wrapper__write_led(LCD_LED_GEO_MIA_INDEX, geo_mia_led);
lcd_wrapper__write_led(LCD_LED_MOTOR_MIA_INDEX, motor_mia_led);

// kph is always in the range of 0 - 10
lcd_wrapper__write_meter(LCD_METER_KPH_INDEX, kph_meter % 11);

// These will be in the Range of 0-99
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_RPM_INDEX, rpm_leddigit % 100);
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_CURRENTDEGREE_INDEX, cdegree_leddigit % 100);
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_REQUIREDDEGREE_INDEX, rdegree_leddigit % 100);
}
</pre>

As we can see the `lcd_ui__update_ui` function was called periodically inside the 1Hz function. It updated the screen in real time based on the static values that were stored AND updated inside the LCD UI module.
The Constant INDEX values stored were directly mapped onto the Index values were received from the 4DWorkshop UI Software.
</li>
</ol>

=== Technical Challenges ===

< List of problems and their detailed resolutions>

<HR>
 

== '''Android Application''' ==
[https://gitlab.com/akhilcherukuri/can-ster_truck_application Gitlab]
=== Software Design ===

<div><ul>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android1.jpg|thumb|none|250px|Splash Screen]]</li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android2.jpg|thumb|none|250px|Main Activity Screen]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android3.jpg|thumb|none|250px|Map Activity Screen]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android4.jpg|thumb|none|250px|Info Activity Screen 1]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android5.jpg|thumb|none|250px|Info Activity Screen 1]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android6.jpg |thumb|none|250px|Debug Activity Screen]]</li>
</ul></div>

The application consists of a total of 5 Activities:

*'''Main Activity:'''
**This is the app launch display screen
**It will check for all the required permission onStart().
**Has search button for connecting from a paired device list view
**Once device is clicked, an intent will start the Map Activity
*'''Map Activity:'''
** For this requirement we are using the Google Maps Fragment, for the map fragment to function we must request an API key from Google and set the key in the manifest of the application.
** Destination marker(Red Marker) is set using setOnMapClickListener to which the car will navigate to, the destination can be changed by clicking elsewhere on the Map Fragment. The marker can be removed using setOnMarkerClickListener.
** When the start button is pressed, the start command identifier along with destination latitude and longitude is sent to the car via the write thread. A background thread is started along with it to indicate the current car's position(Green Marker) along with a plotline between the current position and destination.
** When the stop button is pressed, the stop command identifier is sent to the car, to stop and turn off the car.
*'''Info Activity:'''
** Messages from Geological, Driver, Motor coming from CAN bus are decoded by the Sensor and Bridge controller and sent to the Android application as a string.
** The received string is parsed and categorizes the data to store it in the required textView to be displayed.
** Bluetooth status, Lidar Values, Ultrasonic Sensor Values, Motor Speed, Motor RPM, Motor PWM, Cars' current location, Compass Heading, Distance till Destination, Checkpoint Index is displayed. This was useful for debugging purposes and allowed us to avoid scanning the mounted LCD or CAN Busmaster on PC during drives.
*'''Debug Activity:'''
**The main function of this activity is to check all RAW RX and RAW TX messages and create a log of all the data received and sent.
*'''Bluetooth Connection Service Activity''' :
**This is the background activity that handles all the threads required for transmission and receiving data using Bluetooth connections. It has 3 running threads which is called inside other activities using a handler:
** Accept Thread - Listens to BluetoothServerSocket using listenUsingRfcommWithServiceRecord. In order for the RF communication socket to connect to the HC-05, we used the following UUID: 00001101-0000-1000-8000-00805F9B34FB. This is a generic SSP Bluetooth UUID that enables the socket to directly connected to HC-05 and maintain the connection.
** Connect Thread - Creates a Bluetooth socket using createRfcommSocketToServiceRecord
** Connected Thread - Creates socket.getInputStream(); and socket.getOutputStream(); when bytes are available in input stream it will read them into a buffer.
***All messages for activities are done by Handler mHandler.obtainMessage(); mHandler.sendMessage();

*'''Receieved string''':
** A String is sent to the Bluetooth app from HC-05 and when it receives a string with identifier "$canster", the message is prased accordingly by using the string delimiter ',' and is ended by the newline character '\n' which will remove the data from StringBuffer.
** Example: $canster,37.339334,-121.881123,37.338713,-121.880685,10.123,20.133,30.123,10.5,88.1,99.2,-2,1,44,7,11,22,33,-3,23\n

[[File:CMPE243_S20_T2_BLUETOOTHFLOWCHART.png|thumb|center|650px| Android Application Flowchart]]

=== Technical Challenges ===

<HR>
 

== '''Mangaement''' ==
===Team Management ===
===Git Management===

Git Management amongst 6 team members was definitely a very challenging task. Depending on our initial design we could’ve had a lot of merge conflicts. However those risks were mitigated by spending a LOT of time in the initial stages to decide our pipeline and structure.

<li>There are certain components in our system that were COMMON. For example the CAN initialization, communication and decodes were all similar for the most part between all the 4 Controllers. The utility modules used were also similar in nature</li>
<li>Thus we made a common branch that contained the templates for CAN Nodes (not Controllers), Hardware code and Utility functions.
<ol>
<li>Later this common branch was forked into an individual Controller specific branch (SENSOR, GEO, MOTOR or DRIVER).</li>
<li>Only the Logic folder contained Controller specific code, specific to that controller.</li>
</ol>
<li>This gave us a lot of flexibility since all the team members had similar APIs to work with on all 4 branches. This promoted easy understanding and learning.
<ol>
<li>Many team members frequently worked on 2 or more controllers at a time where can messages were concerned. Having a APIs also meant that just the can_handler needed to be updated regularly followed by the equivalent logic code. </li>
<li>Inside the logic folder, getters to the can node modules were frequently used.</li></ol>
<pre>
├───can_module
│ ├───can_bus_initializer
│ ├───can_constants
│ ├───can_driver_node
│ ├───can_geo_node
│ ├───can_handler
│ ├───can_motor_node
│ ├───can_sensor_node
│ └───test
├───hardware
│ ├───bt
│ ├───compass
│ ├───gps
│ ├───lcd
│ ├───test
│ └───ultrasonic
├───logic
│ ├───driver_obstacle
│ ├───driver_state
│ ├───geo_logic
│ └───test
├───periodics
│ └───test
└───utility
├───line_buffer
└───test
</pre>

'''Challenges'''
<li>It was initially a bit of a learning curve to understand the flow of the repository</li>
<li>When using a git management system with different versions in each branch it became very tough when the number of branches suddenly exploded in size. A lot of relevant code was stuck in a lot of different branches.
<ol>
<li>This happened mainly due to assignment submissions and unclosed MRs that eventually became stale.</li>
<li>Our strategy was to abandon these MRs and keep forking from these branches without merging it back into its final controller branch.</li>
<li>The latest branches that were kept were aptly named `<controller>_bleeding_edge_dev` branches since they were never merged back from where they were forked.</li>
</ol>
<li>Since a lot of our code also depended on the DBC autogenerated code, we could not suddenly change the DBC Message names once they were established since it caused a change in the Struct name that was generated and used.
<ol>
<li>Our solution to this was to keep everything backward compatible. We added new function names without deleting old DBC messages.</li>
<li>In certain places where we wanted to modify a function name it was done one by one so that a lot of the code is not broken at one time.</li>
</ol>
<li>Common Branches eventually became stale as our progress continued on the bleeding edge branches
<ol>
<li>For example certain GPS features needed to be added which were done on the GEO_bleeding_edge_dev branch but never pushed or cherry-picked back into the COMMON branch.</li>
<li>This was a similar issue to our 2nd point but manageable since the goal of the COMMON branch was to provide a template for further work and nothing more.</li>
<li>At the end of the day each controller is its own Individual Project and while the messages between them are same. The Hardware code does not need to be same.</li>
<li>This also prompted team-members to ask if we could delete unused hardware or logic file code (which wasn’t being used and was imported from the template). This was also fine and can be done during cleanup stage. However we eventually got used to the Modular system of our project so much so that we did not worry about the additional modules that were present in each branched controller project.</li>
</ol>

<HR>
 

== '''Conclusion''' ==
CMPE243 gives one of the best experiences one could ever get in their academic life. The course is designed to give an insight into how the industry functions and enhances both technical and management skills. Apart from learning how to work and implement application of CAN protocol, one can get a hands-on experience with version control, unit-testing and software design. Overall it was a very great journey.

=== Project Video ===

=== Project Source Code ===

=== Advise for Future Students ===
'''GENERAL:'''
* Form your team and start the project as early as you can.
* Clearly discuss what role each individual should do and ensure that progress is regularly tracked so that the team doesn't fall back on any schedule.
* Since lot of code and hardware integration is involved with this project, make sure testing is thoroughly and periodically done and make note of all the issues found.
'''HARDWARE:'''
* Decide on how you would power up the peripherals. We had issues with Bluetooth (not connecting), GPS (lock not happening) and LIDAR (giving incorrect values). After lot of cycles of hardware and software debugging, we found that the issue was with power. Choose wisely as to which peripherals must be connected to which power bank.
* PCB design is time consuming as there is a lot of hardware components involved and a huge responsibility falls on the designer to know the about each component. Coordinating with multiple team members and verifying with them if their respective hardware is correct takes a lot of time. So start well ahead.
* Make sure to expose some extra GPIO and GND pins for future use.
'''MOTOR:'''
*You can use the LiPo battery to power the RPM and servo motor instead of using a separate power source. Use Vout from the ESC to get 6V.
*Start the PID control calibration early on as you will need to do extensive testing to get it working.

=== Acknowledgement ===
<HR>
Firstly we would like to express our gratitude to Professor Preetpal Kang for his guidance throughout the semester and providing us with this opportunity. We would also like to thank the ISA members Vignesh Kumar Venkateshwar and Aakash Vrajlal Chitroda for being available whenever in need and guiding us to complete the project.

== '''References''' ==

===Motor Controller===
===Geological Controller===
* Movable Scripts: [https://www.movable-type.co.uk/scripts/latlong.html Calculate distance, bearing and more between Latitude/Longitude points]
* CMPS11:[https://www.robot-electronics.co.uk/htm/cmps11i2c.htm I2C Configuration]

===Bridge and Sensor Controller===
===Driver and LCD Controller===
*LCD Software: [https://4dsystems.com.au/ulcd-32ptu 4Dsystems]
===Android===
*Youtube Channel: [https://www.youtube.com/channel/UCoNZZLhPuuRteu02rh7bzsw Coding with Mitch]
*Android Developers: [https://developer.android.com/guide/topics/connectivity/bluetooth Website][https://github.com/googlearchive/android-BluetoothChat Github]
*Udemy Course: [https://www.udemy.com/course/the-complete-android-oreo-developer-course/ Complete Android Oreo Developer Course]
===PCB Design===
*EDC Tool: [https://easyeda.com/ EasyEDA]

S20: Canster Truck

2020-05-22T05:38:11Z

Proj user22: /* GEO Logic Module Computation */

[[File:CMPE243_S20_T2_Canster_Truck_Logo.png|thumb|455px|caption|right|CAN-STER TRUCK LOGO]]

== '''Abstract''' ==
'''The Canster Truck Project is an autonomous RC car with CAN Bus interfaced controllers. The development of the RC car's subsystem modules (Interfacing of Ultrasonic Sensor, LIDAR, Bluetooth, GPS, Compass and CAN modules) was divided among six team members. The aim of the project is to develop an autonomous RC Car which can navigate from one source location to the selected destination on the app by avoiding obstacles in its path using sensors. Waypoints algorithm is used as the path finding technique.'''

 

== '''Introduction and Objectives''' ==

'''The project was divided into 7 modules:'''

* '''Bridge and Sensor Controller'''
* '''Motor Controller'''
* '''Geological Controller'''
* '''Driver and LCD Controller'''
* '''Hardware Integration'''
* '''Android Application'''
* '''Testing & Code Review'''

'''RC Car Objectives'''
'''1. Driver and LCD Controller''' - Handles algorithms for obstacle avoidance, route maneuvering, and waypoints
'''2. Geological Controller''' - Recieves coordinates from GPS and Heading from Compass for navigation
'''3. Motor Controller''' - Controls movements of the RC Car
'''4. Bridge and Sensor Controller''' - Detects surrounding objects and interfaces android application to controller via bluetooth
'''Team Objectives'''

[[File:CMPE243_S20_T2_High_Level_System_Diagram.png|thumb|center|800px| High Level System Diagram]]

 

== '''Team Members and Responsibilities''' ==

'''Gitlab Project Link''' - [https://gitlab.com/coder137/can-ster_truck '''Canster Truck''']
 

*'''Niket Naidu''' [https://www.linkedin.com/in/niket-naidu-30090a134/ LinkedIn] [https://gitlab.com/coder137 Gitlab]
** '''Geological Controller''' : Waypoint Algorithm, Haversine and Bearing Angle logic
** '''Driver and LCD Controller''' : GLCD
** '''Bridge and Sensor Controller''' : Bluetooth
** '''Testing & Code Review'''

*'''Ganesh Ram Pamadi''' [https://www.linkedin.com/in/ganeshram93/ LinkedIn] [https://gitlab.com/ganeshram2493 Gitlab]
** '''Hardware Integration'''
** '''Testing & Code Review'''
** '''Driver Controller'''
** '''Motor Controller'''

*'''Nikhil Pabbisetty''' [https://www.linkedin.com/in/nikhilpabbisetty/ LinkedIn] [https://gitlab.com/nikhilpeoria Gitlab]
** '''Bridge and Sensor Controller'''
** '''Motor Controller'''

*'''Akhil Cherukuri''' [https://www.linkedin.com/in/akhilcherukuri/ LinkedIn] [https://gitlab.com/akhilcherukuri Gitlab] [https://github.com/akhilcherukuri Github]
** '''Android Application'''
** '''Bridge and Sensor Controller'''

*'''Ashish Anant Ladage''' [https://www.linkedin.com/in/ashish-anant-ladage-7bb3a214b/ LinkedIn] [https://gitlab.com/ashishladage1 Gitlab]
** '''Driver and LCD Controller'''
** '''Hardware Integration'''
** '''Motor Controller'''

*'''Jesus De Haro De Reza''' [https://www.linkedin.com/in/jesus-de-haro-66342424/ LinkedIn] [https://gitlab.com/deharo27 Gitlab]
** '''Bridge and Sensor Controller'''
** '''Motor Controller'''

 

== '''Administrative Responsibilities''' ==
* '''Team Lead''' - [https://www.linkedin.com/in/niket-naidu-30090a134/ '''Niket Naidu''']
* '''Git Repository Manager''' - [https://www.linkedin.com/in/niket-naidu-30090a134/ '''Niket Naidu''']
* '''Bill Of Materials Manager''' - [https://www.linkedin.com/in/akhilcherukuri '''Akhil Cherukuri''']
* '''Wiki Report Manager''' - [https://www.linkedin.com/in/akhilcherukuri '''Akhil Cherukuri''']

 

== '''Schedule''' ==

{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-

! scope="row"| '''1'''
| style="text-align:center;" |'''02/11/2020'''
| style="text-align:center;" |'''02/17/2020'''
|
*'''Form teams and decide group name'''
*'''Review past projects'''
*'''Slack: Create project group and invite Preet'''
*'''GitLab: Create project groups repository'''
*'''Analysis of component required'''

|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''2'''
| style="text-align:center;" |'''02/18/2020'''
| style="text-align:center;" |'''02/24/2020'''
|
*'''Study CAN Communication'''
*'''Create Bill of Materials'''
*'''Order RC Car'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''3'''
| style="text-align:center;" |'''02/25/2020'''
| style="text-align:center;" |'''03/02/2020'''
|
*'''Setup team finance management using Splitwise application'''
*'''Complete Bill of Materials'''
*'''Order all other required components'''
*'''Wikipedia: Setup project report template'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''4'''
| style="text-align:center;" |'''03/03/2020'''
| style="text-align:center;" |'''03/09/2020'''
|
*'''Read the respective datasheets and manuals for each component'''
*'''Test each component for working conditions'''
|
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''5'''
| style="text-align:center;" |'''03/10/2020'''
| style="text-align:center;" |'''03/16/2020'''
|
*'''Assign team responsibilities and roles'''
*'''Setup team project management environment (ClickUp)'''
*'''Define CAN DBC'''
*'''Research GPS antennas and order'''
*'''Android: Environmental setup of Android Studio and enable version control'''
*'''Hardware : Decide PCB editing software (easyEDA)'''
*'''Hardware : Draft schematic for required PCB design'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''6'''
| style="text-align:center;" |'''03/17/2020'''
| style="text-align:center;" |'''03/23/2020'''
|
*'''Hardware : Create model of PCB''' 
*'''Android: Add a Button for changing bluetooth connection status in the application''' 
*'''Geological: Interface Compass module with SJ-2 board using I2C interface''' 
*'''Geological: Interface GPS module with SJ-2 board using the UART interface''' 
*'''Geological: Parse raw data to get meaningful values for GPS and Compass''' 
*'''Sensor: Interface and check the functionality of ultrasonic sensors to the SJ-2 board''' 
*'''Motor: Interface of Servo & DC motor to the SJ-2 board and check for basic functionality''' 
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''7'''
| style="text-align:center;" |'''03/24/2020'''
| style="text-align:center;" |'''03/30/2020'''
|
*'''Hardware : Finalize components placement on PCB.''' 
*'''Motor: Add PWM functionality and test the code on DC and servo motors''' 
*'''Sensor: Interface and check and study the output readings of Lidar sensor with SJ-2 board over UART''' 
*'''LCD Display: Explore UI designing of LCD''' 
*'''Hardware: Finalize on optimal ultrasonic sensor placements''' 
*'''Android: Initiate Bluetooth communication and show staus via text view''' 
*'''Wikipedia: Establish final wiki schedule'''
*'''Complete CAN communication format for each controller and link DBC file to the Wiki'''
*'''Complete high-level system block diagram'''
*'''Complete unit-level block diagrams'''
*'''Bridge: Interface HC-5 bluetooth module with Sj-2 board using serial communicaton'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''8'''
| style="text-align:center;" |'''03/31/2020'''
| style="text-align:center;" |'''04/06/2020'''
|
*'''Hardware: Analyze PCB model and order PCB Circuit board''' 
*'''Android: Initiate Bluetooth communication and send "Hello World".''' 
*'''Wikipedia: Start adding information/images/diagrams to the relevant sections'''
*'''Motor: Configure ESC for correct speed outcome according to frequency & PWM values''' 
*'''Motor: Finish RPM sensor hardware and software implementation and integration''' 
*'''Sensor: Read output from Lidar and setup structure for outputting for DBC''' 
*'''Geological: Implement waypoints algorithm''' 
*'''Driver: Implement obstacle avoidance algorithm''' 
*'''Bridge: Pass data such as "Hello World" from HC-05 bluetooth module to bluetooth terminal android application'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''9'''
| style="text-align:center;" |'''04/07/2020'''
| style="text-align:center;" |'''04/13/2020'''
|
*'''Hardware: Remove Unused parts from RC Car''' 
*'''Hardware: Mount PCB and 3D Parts''' 
*'''Motor: Decide different cut-off values from sensor to command right /slight right/ straight/ slight left/ left to motor.''' 
*'''Android: Embed Google Maps API for setting the car's destination.''' 
*'''LCD: Work to show RC cars live status information(battery level, current speed, long, lat, bearing, sensor data, etc)''' 
*'''Driver: Test obstacle avoidance algorithm and fine-tune sensor readings''' 
*'''Geological: Test checkpoint algorithm''' 
*'''Bridge: Establish two way communication between android application and bluetooth module''' 
*'''Update Bill of Materials for miscellaneous hardware'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''10'''
| style="text-align:center;" |'''04/14/2020'''
| style="text-align:center;" |'''04/20/2020'''
|
*'''Hardware: Integrate all hardware modules''' 
*'''LCD: Testing & Validation of the LCD UI and display vehicle status information''' 
*'''Android: Send car location to the app and checkpoints received to Geo module''' 
*'''Motor: Optimize PID control by accelerating/decelerating as instructed by Driver''' 
*'''Bridge: Configure HC-05 for auto reconnection if bluetooth communication disconnects''' 
*'''Add multiple debug messages and transmit on CAN'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''11'''
| style="text-align:center;" |'''04/21/2020'''
| style="text-align:center;" |'''04/27/2020'''
|
*'''Android: Send additional vehicle status information from RC car to the Application for display''' 
*'''Android: Finalize User Interface Design and Icon''' 
*'''Continuously test the whole system and handling of corner cases (outside).'''
*'''Finalize RC Car For Project Proto 1'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''12'''
| style="text-align:center;" |'''04/28/2020'''
| style="text-align:center;" |'''05/04/2020'''
|
*'''Gitlab: Push final code'''
*April 28th: Project Proto 1
*'''Finalize RC Car for Project Demo'''
*May 1st: Project Presentation
*'''Finalize RC Car for Project Proto 2'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''13'''
| style="text-align:center;" |'''05/05/2020'''
| style="text-align:center;" |'''05/21/2020'''
|
* '''Complete Individual Contribution Peer Grading'''
* '''Review and Complete Wiki Project Page'''
|
*'''Completed'''
*'''In Progress'''
|-
|}

 

== '''Bill Of Materials''' ==
{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Item#
! scope="col"| Part Description
! scope="col"| Part Model & Vendor
! scope="col"| Quantity
! scope="col"| Cost in USD
|-
! scope="row"| 1
| '''Microcontroller Boards'''
| SJ2 Boards (Purchased from Preet Kang)
| 4
| $200.00
|-
! scope="row"| 2
| '''CAN Transceivers'''
| [https://www.waveshare.com/sn65hvd230-can-board.htm Waveshare SN65HVD230]
| 12
| $54.48
|-
! scope="row"| 3
| '''RC Car'''
| [https://www.amazon.com/Traxxas-Slash-Course-2-4GHZ-Vehicle/dp/B01DU474B0/ref=sr_1_3?ie=UTF8&qid=1474747759&sr=8-3&keywords=Traxxas+1%2F10+slash+2wd Traxxas 2WD RTR with 2.4Ghz Radio]
| 1
| $260.00
|-
! scope="row"| 4
| '''Lithium-Ion Battery'''
| [https://www.rcsuperstore.com/traxxas-7600mah-2s-7-4v-25c-id-lipo-battery-pack/ Traxxas 7600mAh 2S 7.4V 25C iD LiPo Battery Pack]
| 1
| $75.00
|-
! scope="row"| 5
| '''Lithium-Ion Battery Charger'''
| [https://www.amazon.com/Traxxas-2970-EZ-Peak-Charger-Identification/dp/B00OAFYLJC/ref=pd_bxgy_21_img_2?ie=UTF8&psc=1&refRID=JVX791WVV9Y8T9DW92KW Traxxas 2970 EZ-Peak Plus 4-Amp NiMH/LiPo Fast Charger]
| 1
| $50.00
|-
! scope="row"| 6
| '''Compass Breakout Board'''
| [https://www.dfrobot.com/product-1275.html DFRobot CMPS11 Compass]
| 1
| $29.99
|-
! scope="row"| 7
| '''Bluetooth Breakout Board'''
| [https://www.amazon.com/HC-05-Bluetooth-Pass-through-Wireless-Communication/dp/B01G9KSAF6/ref=sr_1_4?ie=UTF8&qid=1507077325&sr=8-4&keywords=arduino+bluetooth+hc-05 DSD TECH Bluetooth HC-05]
| 1
| $8.49
|-
! scope="row"| 8
| '''LIDAR Sensor'''
| [https://www.amazon.com/RPLiDAR-A1M8-Degree-Laser-Scanner/dp/B07H7X3SFF/ref=sr_1_fkmrnull_1?crid=2FSUI76G4UA8K&keywords=rplidar+a1m8+-+360+degree+laser+scanner+development+kit&qid=1552764172&s=gateway&sprefix=RPlidar%2Caps%2C263&sr=8-1-fkmrnull SEEED STUDIO RPLIDAR A1M8]
| 1
| $109.99
|-
! scope="row"| 9
| '''RPM Sensor'''
| [https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM Traxxas 6520 RPM Sensor]
| 1
| $13.70
|-
! scope="row"| 10
| '''GPS Breakout Board'''
| [https://www.adafruit.com/product/746 Adafruit Ultimate GPS Breakout v3]
| 1
| $44.30
|-
! scope="row"| 11
| '''LCD Display'''
| [https://4dsystems.com.au/ulcd-32ptu 4Dsystems 3.2 TFT-LCD ULCD-32PTU]
| 1
| $79.00
|-
! scope="row"| 12
| '''Ultrasonic Sensors'''
| [https://www.amazon.com/gp/product/B01COSN7O6/ ELEGOO HC-SR04 Ultrasonic Module]
| 5
| $12.00
|-
! scope="row"| 13
| '''GPS Antenna'''
| [https://www.amazon.com/dp/B07RRT615K/ GPS Antenna A1-UX]
| 1
| $10.98
|-
! scope="row"| 14
| '''PCB Fabrication'''
| [https://jlcpcb.com/ JLCPCB]
| 5
| $40.15
|-
! scope="row"| 15
| '''Miscellaneous'''
| [https://www.amazon.com Amazon],[https://www.mouser.com/ Mouser Electronics],[https://www.digikey.com/ Digikey],[https://anchor-electronics.com/ Anchor Electronics]
| ~
| $48.07
|-
! scope="row"|
|
|
| '''Total'''
| '''$1036.15'''
|-

|}

 

== '''Printed Circuit Board''' ==

=== Design And Architecture ===
The complete PCB (for boards and hardware peripherals) was designed using EasyEDA online software. The 4 nodes will be communicating via CAN bus and other peripherals are connected to the PCB via headers.

=== Power Section===
We have 2 power banks supplying our system. And the Servo Motor, RPM sensor and DC rear Motor (via ESC) are powered using LiPo battery (6 volts).
* Power bank #1 - Subset 2

* Power bank #2 - Subset 1, Subset 3, Bluetooth

'''NOTE:'''

'''Subset 1:'''
1. LIDAR
2. LCD
3. Compass

'''Subset 2:'''
1. Motor node
2. Driver node
3. BS node

'''Subset 3:'''
1. Geo node
2. Back ultrasonic sensor

=== Fabrication ===
* PCB was sent to fabrication to JLCPCB China which provided PCB with MOQ of 5 and 2 layers of PCB with common grounded the entire copper area.
'''DRC elements'''
* Track Width = 12
* Clearance = 10
* Via Diameter = 24
* Via Drill Diameter = 12

=== Challenges ===
* Auto-routing gave lot of challenges (only ~60% success) and sometimes the online server even crashes and faces downtime. Even local routing had lot of issues. So make sure to plan your design accordingly.
* We started our PCB design well ahead of the project. So lot of pre-planning had to be done with regard to final hardware and placement of components in order to avoid spending extra time and money while re-ordering.
* The PCB went through a lot of internal revisions even before placing order. This was time-consuming.

'''Other hardware challenges:'''
* Figuring out why various hardware peripherals (GPS, Bluetooth, LIDAR and Ultrasonic sensor) started to malfunction (devices were on but values were either inconsistent / not occurring), took a lot of time to debug. It was due to insufficient power.

 

[[File:CMPE243 S20 T2 EasyEDA.png|1040x1200px|thumb|center|PCB Layout Design in EasyEDA]]
[[File:CMPE243 S20 T2 PCB SCHEMATIC.jpg|1041x550px|thumb|center|PCB Schematic]]

<div><ul>
<li style="display: inline-block;"> [[File:CMPE243 S20 T2 PCBFRONT.jpg|thumb|none|600px|PCB Top Layer]] </li>
<li style="display: inline-block;"> [[File:CMPE243 S20 T2 PCBBACK.jpg|thumb|none|600px|PCB Bottom Layer]] </li>
</ul></div>

 

== '''CAN Communication''' ==
<Talk about your message IDs or communication strategy, such as periodic transmission, MIA management, etc.>

=== Hardware Design ===
<Show your CAN bus hardware design>

=== DBC File ===

DBC FILE: [https://gitlab.com/coder137/can-ster_truck/-/blob/dbc-improvements/projects/lpc40xx_freertos/project.dbc Gitlab]

<pre>
VERSION ""

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

BS_:

BU_: DBG DRIVER IO MOTOR SENSOR GEO

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" GEO,MOTOR,SENSOR

BO_ 101 GEO_HEARTBEAT: 1 GEO
SG_ GEO_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,MOTOR,SENSOR

BO_ 102 MOTOR_HEARTBEAT: 1 MOTOR
SG_ MOTOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,SENSOR

BO_ 103 SENSOR_HEARTBEAT: 1 SENSOR
SG_ SENSOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,MOTOR

BO_ 200 MOTOR_STEERING: 1 DRIVER
SG_ MOTOR_STEERING_direction: 0|8@1- (1,0) [-2|2] "" MOTOR

BO_ 210 DRIVER_COORDINATES: 8 DRIVER
SG_ DRIVER_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
SG_ DRIVER_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 220 MOTOR_SPEED: 1 DRIVER
SG_ MOTOR_SPEED_processed: 0|8@1- (1,0) [-3|3] "" MOTOR

BO_ 300 GEO_DEGREE: 8 GEO
SG_ GEO_DEGREE_current: 0|32@1+ (0.000001,0) [0|360] "degrees" DRIVER
SG_ GEO_DEGREE_required: 32|32@1+ (0.000001,0) [0|360] "degrees" DRIVER

BO_ 310 GEO_DESTINATION_REACHED: 1 GEO
SG_ GEO_DESTINATION_REACHED_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 400 MOTOR_SPEED_FEEDBACK: 4 MOTOR
SG_ MOTOR_SPEED_current: 0|32@1+ (0.1,0) [0|60] "kph" DRIVER

BO_ 500 SENSOR_BT_COORDINATES: 8 SENSOR
SG_ SENSOR_BT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
SG_ SENSOR_BT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 510 SENSOR_SONARS: 8 SENSOR
SG_ SENSOR_SONARS_left: 0|21@1+ (0.001,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right: 21|21@1+ (0.001,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle: 42|21@1+ (0.001,0) [0|0] "cm" DRIVER

BO_ 520 SENSOR_LIDAR: 8 SENSOR
SG_ SENSOR_LIDAR_middle: 0|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_slight_left: 16|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_slight_right: 32|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_back: 48|16@1+ (1,0) [0|0] "cm" DRIVER

BO_ 530 MOTOR_KEY: 1 SENSOR
SG_ MOTOR_KEY_val: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 900 GEO_CURRENT_COORDINATES: 8 GEO
SG_ GEO_CURRENT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" DBG
SG_ GEO_CURRENT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" DBG

BO_ 901 GEO_DISTANCE_FROM_DESTINATION: 4 GEO
SG_ GEO_distance_from_destination: 0|32@1+ (0.001,0) [0|0] "meters" DBG

BO_ 902 MOTOR_INFO_DBG: 4 MOTOR
SG_ MOTOR_INFO_DBG_rps: 0|16@1+ (1,0) [0|0] "" DBG
SG_ MOTOR_INFO_DBG_pwm: 16|16@1+ (0.001,0) [0|0] "" DBG

BO_ 903 LIPO_BATTERY_VOLTAGE_DBG: 4 MOTOR
SG_ LIPO_BATTERY_VOLTAGE_val: 0|32@1+ (0.01,0) [0|0] "volts" DBG

BO_ 904 CURRENT_CHECKPOINT_DBG: 1 GEO
SG_ CURRENT_CHECKPOINT_val: 0|8@1+ (1,0) [0|0] "" DBG

CM_ "--BU (Network Node) Information--";
CM_ BU_ DRIVER "The driver controller of the car";
CM_ BU_ GEO "The geo controller of the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";

CM_ "--BO (Message) Information--";
CM_ BO_ 100 "Driver Sync message used to synchronize the controllers";
CM_ BO_ 101 "Geo Sync message used to synchronize the controllers";
CM_ BO_ 102 "Motor Sync message used to synchronize the controllers";
CM_ BO_ 103 "Sensor Sync message used to synchronize the controllers";

CM_ BO_ 200 "Steering direction values sent by Driver Node to Motor Node";
CM_ BO_ 210 "Driver Destination coordinates sent by Driver Node";
CM_ BO_ 220 "Required motor speed computed from Driver Node to Motor Node";

CM_ BO_ 300 "Current and computer/required degree values sent by Geo Node";
CM_ BO_ 310 "Indicator signal to check if the RC car has reached the destination";

CM_ BO_ 400 "Current motor info (rps and kph) sent as feedback to the Driver Node";

CM_ BO_ 500 "Coordinate BT values (destination coordinates) sent by Sensor Node";
CM_ BO_ 510 "LIDAR - Distance from obstacle detected in each sector";
CM_ BO_ 520 "Ultrasonic Sensor - Distance from obstacle detected by each sensor";
CM_ BO_ 530 "Start/Stop signal from the Bluetooth app";

CM_ BO_ 900 "Destination coordinates for BUSMASTER debugging";
CM_ BO_ 901 "Distance from destination";
CM_ BO_ 902 "Supplied PWM value to the motor and its RPM";
CM_ BO_ 903 "LIPO Battery Voltage";
CM_ BO_ 904 "Current checkpoint of the car";

CM_ "--SG (Signal) Information for Heartbeats--";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver node";
CM_ SG_ 101 GEO_HEARTBEAT_cmd "Heartbeat command from the geological node";
CM_ SG_ 102 MOTOR_HEARTBEAT_cmd "Heartbeat command from the motor node";
CM_ SG_ 103 SENSOR_HEARTBEAT_cmd "Heartbeat command from the sensor node";

CM_ "--SG (Signal) Information for DRIVER Node--";
CM_ SG_ 200 DRIVER_STEERING_direction "Calculated Driver Steering values (-2,2) for Motor";
CM_ SG_ 210 DRIVER_COORDINATES_latitude "Destination Latitude coordinate";
CM_ SG_ 210 DRIVER_COORDINATES_longitude "Destination Longitude coordinate";
CM_ SG_ 220 MOTOR_SPEED "Calculated Driver speed values (-3,3) for Motor";

CM_ "--SG (Signal) Information for GEO Node--";
CM_ SG_ 300 GEO_DEGREE_current "Current Geo Degree relative to true north";
CM_ SG_ 300 GEO_DEGREE_required "Calculated Geo Degree computed by Haversine Formula";
CM_ SG_ 310 GEO_DESTINATION_REACHED "Indicator signal to check if the RC car has reached the destination";

CM_ "--SG (Signal) Information for MOTOR Node--";
CM_ SG_ 400 MOTOR_SPEED_FEEDBACK "Feedback speed (kph) sent by Motor Node";

CM_ "--SG (Signal) Information for SENSOR Node--";
CM_ SG_ 500 SENSOR_BT_COORDINATES_latitude "Destination Latitude received over Bluetooth";
CM_ SG_ 500 SENSOR_BT_COORDINATES_longitude "Destination Longitude received over Bluetooth";
CM_ SG_ 510 SENSOR_SONARS_left "Ultrasonic Sensor attached to the left side";
CM_ SG_ 510 SENSOR_SONARS_right "Ultrasonic Sensor attached to the right side";
CM_ SG_ 510 SENSOR_SONARS_middle "Ultrasonic Sensor attached to the middle";
CM_ SG_ 510 SENSOR_SONARS_back_left "Ultrasonic Sensor attached to the back left side";
CM_ SG_ 510 SENSOR_SONARS_back_right "Ultrasonic Sensor attached to the back right side";
CM_ SG_ 520 SENSOR_LIDAR_middle "Lidar sensing the middle sector (-15 to 15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_left "Lidar sensing the slight left sector (-45 to -15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_right "Lidar sensing the slight right sector (15 to 45 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_back "Lidar sensing the back of the car (165 to 195 degrees)";
CM_ SG_ 530 MOTOR_KEY_val "1 -> Start the motor from the app, 0 -> Stop";

CM_ SG_ 900 GEO_CURRENT_COORDINATES_latitude "Current Latitude";
CM_ SG_ 900 GEO_CURRENT_COORDINATES_longitude "Current Longitude";
CM_ SG_ 901 GEO_distance_from_destination "Distance from destination";
CM_ SG_ 902 MOTOR_INFO_DBG_rps "Current RPS value of the motor";
CM_ SG_ 902 MOTOR_INFO_DBG_pwm "Supplied motor PWM value";
CM_ SG_ 903 LIPO_BATTERY_VOLTAGE_val "LIPO Battery Voltage";
CM_ SG_ 904 CURRENT_CHECKPOINT_val "Current checkpoint of the car";

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

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

BA_ "GenMsgCycleTime" BO_ 100 1000;
BA_ "GenMsgCycleTime" BO_ 200 50;
BA_ "FieldType" SG_ 100 DRIVER_HEARTBEAT_cmd "DRIVER_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 102 GEO_HEARTBEAT_cmd "GEO_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 103 MOTOR_HEARTBEAT_cmd "MOTOR_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 104 SENSOR_HEARTBEAT_cmd "SENSOR_HEARTBEAT_cmd";

BA_ "FieldType" SG_ 200 MOTOR_STEERING "MOTOR_STEERING";
BA_ "FieldType" SG_ 230 MOTOR_SPEED_val "MOTOR_SPEED_val";
BA_ "FieldType" SG_ 310 GEO_DESTINATION_REACHED_cmd "GEO_DESTINATION_REACHED_cmd";

VAL_ 100 DRIVER_HEARTBEAT_cmd 2 "DRIVER_HEARTBEAT_cmd_REBOOT" 1 "DRIVER_HEARTBEAT_cmd_SYNC" 0 "DRIVER_HEARTBEAT_cmd_NOOP" ;
VAL_ 101 GEO_HEARTBEAT_cmd 2 "GEO_HEARTBEAT_cmd_REBOOT" 1 "GEO_HEARTBEAT_cmd_SYNC" 0 "GEO_HEARTBEAT_cmd_NOOP";
VAL_ 102 MOTOR_HEARTBEAT_cmd 20 "MOTOR_HEARTBEAT_cmd_REBOOT" 10 "MOTOR_HEARTBEAT_cmd_SYNC" 0 "MOTOR_HEARTBEAT_cmd_NOOP" ;
VAL_ 103 SENSOR_HEARTBEAT_cmd 200 "SENSOR_HEARTBEAT_cmd_REBOOT" 100 "SENSOR_HEARTBEAT_cmd_SYNC" 0 "SENSOR_HEARTBEAT_cmd_NOOP" ;

VAL_ 200 MOTOR_STEERING_direction -2 "MOTOR_STEERING_hard_left" -1 "MOTOR_STEERING_slight_left" 0 "MOTOR_STEERING_straight" 1 "MOTOR_STEERING_slight_right" 2 "MOTOR_STEERING_hard_right";
VAL_ 220 MOTOR_SPEED_processed -3 "MOTOR_SPEED_reverse_fast" -2 "MOTOR_SPEED_reverse_medium" -1 "MOTOR_SPEED_reverse_slow" 0 "MOTOR_SPEED_neutral" 1 "MOTOR_SPEED_forward_slow" 2 "MOTOR_SPEED_forward_medium" 3 "MOTOR_SPEED_forward_fast";
VAL_ 310 GEO_DESTINATION_REACHED_cmd 1 "GEO_DESTINATION_REACHED_cmd_REACHED" 0 "GEO_DESTINATION_REACHED_cmd_NOT_REACHED";
</pre>

 

== '''Motor Controller''' ==
<Picture and link to Gitlab>

This controller is used to control the components of the car-related to motor. We can control the speed and steering of the car having interfaced with various components with the SJ-2 board. The servo motor is controlled via PWM and is used to set the steering direction of the car. The DC motor is controlled by the Electronic Speed Controller (ESC) via PWM for speed. We read the speed of the car by using an RPM sensor. By using the RPM sensor values, a feedback loop has been designed to regulate the speed of the car. A state machine has been designed to manage the forward and backward movements of the car.
Additionally, a voltage divider circuit has been implemented to read the battery voltage. All motor functionality and CAN message communication is run at 10 Hz.

=== Hardware Design ===

The following diagram details the hardware implementation of the motor module with the SJTwo board:
Hardware Interface
- Servo Motor
The servo motor responds to PWM pulses. It has three pins namely Vcc, PWM Input Signal, and GND. The servo is powered using 6V from the car battery. Based on the PWM signal supplied from the SJTwo board the front wheels are turned.
- Electronic Speed Controller (ESC)
The ESC is used to control the DC motor. It is supplied power using the 7.4 V LiPo battery. It has three pins namely Vout, PWM Input Signal, and GND. Based on the PWM input signal, the speed and forward, neutral, and backward movements of the car is changed. Vout is given to the RPM sensor and Servo motor.
- DC Motor
The DC motor is controlled using the ESC. It has two pins, a positive and negative terminal. A PWM signal wire is connected to the microcontroller and the required current is provided by the LiPo battery and the ESC. The DC motor is controlled using PWM at 10Hz.

[[File:CMPE243_S20_T2_Canster_Truck_Motor_Hardware.png|thumb|center|750px| Motor Hardware System]]

Note: First calibrate the DC motor or the motor will not respond to your PWM pulses. For help with calibration go to this [https://traxxas.com/support/Programming-Your-Traxxas-Electronic-Speed-Control website]

- RPM Sensor

The RPM sensor is used to get the current speed of the car. We use the info for creating a feedback loop (PID) for maintaining the speed of the car in uphill and downhill situations. The RPM sensor mounts on the rear DC motor shaft compartment with a special assembly also provided by Traxxas. The magnet which attached to the inner gear generates a pulse each rotation. The sensor works on the hall effect principle where it provides a current across its terminal when placed in a magnet's field. The RPM sensor has three pins namely Vcc, Signal, and GND.

- Battery Voltage Divider Circuit
- (Need Niket’s help)

=== Software Design ===

The software for the motor node was divided into multiple files and made modular to improve readability and understanding of the complex logic involved. The main code modules are for:
• Servo Motor
• Electronic Speed Controller
• RPM Sensor
• Motor Wrapper
• Battery Voltage

The motor wrapper module is used to wrap all the code from the esc, servo, and rpm modules into simple to use functions to be called in the periodic tasks.
• Servo Motor
It uses the steering value sent from the driver (-2 to 2) and matches it to the appropriate PWM value for steering. This code module is run at 10Hz.
<pre>
void servo__steer_processor(int16_t steering_value) {
switch (steering_value) {
case MOTOR_STEERING_hard_left:
servo__steer_hard_left();
break;
case MOTOR_STEERING_slight_left:
servo__steer_soft_left();
break;
case MOTOR_STEERING_straight:
servo__steer_straight();
break;
case MOTOR_STEERING_slight_right:
servo__steer_soft_right();
break;
case MOTOR_STEERING_hard_right:
servo__steer_hard_right();
break;
default:
printf("\nDid not receive steering value");
}
}
</pre>
• Electronic Speed Controller

This code module is used to control the DC motor. It receives the motor direction value from the driver and sets the appropriate PWM value. Based on the value the motor is commanded to move the car forward or backwards. A switch case is implemented to set PWM values for movement in different directions along with different speeds.
<pre>
void esc__direction_processor(int16_t direction_value) {
desired_direction_value = direction_value;
switch (direction_value) {
case MOTOR_SPEED_reverse_fast:
esc__reverse_fast();
break;
case MOTOR_SPEED_reverse_medium:
esc__reverse_medium();
break;
case MOTOR_SPEED_reverse_slow:
esc__reverse_slow();
break;
case MOTOR_SPEED_neutral:
esc__neutral();
break;
case MOTOR_SPEED_forward_slow:
esc__forward_slow();
break;
case MOTOR_SPEED_forward_medium:
esc__forward_medium();
break;
case MOTOR_SPEED_forward_fast:
esc__forward_fast();
break;

default:
printf("\nDid not receive direction and speed value");
}
}
</pre>

There is also a feedback loop to control the speed. The ESC code depends on the rpm sensor code for the current speed values.
<pre>
double current_speed = get_speed_kph();
double desired_speed = desired_speed_kph;
float adjusted_duty_cycle = 0.0;
adjusted_duty_cycle = duty_cycle + (speed_to_pwm_adjustment(desired_speed, current_speed));
</pre>

[[File:CMPE243_S20_T2_Canster_Truck_Motor1.png|thumb|center|400px| Motor Flowchart 1]]

• RPM Sensor
This code module is used to get current speed data from the RPM sensor. It is based on interrupts. When the wheel rotates once, we get one pulse due to the magnet installed. This pulse generates a falling edge interrupt during which we increment the pulse counter. Since, this code is run at 1Hz we collect the number of pulses generated every one second. This gives us the number of rotations per second using which we can calculate the speed in kph.
<pre>
float rpm__calculate_speed_kph() {
uint16_t rotation_per_sec = pulse_count;
pulse_count = 0;
speed_kph = ((CIRCUMFERENCE_METER * rotation_per_sec) * (MPS_TO_KPH_CONVERSION_FACTOR)) / GEAR_RATIO;
return speed_kph;
}
</pre>

• Motor Wrapper
As mentioned above, the main function of this code module is to wrap all the other code modules and call the right functions at the appropriate frequency. The motor wrapper code also includes a state machine for ensuring a smooth transition between forward to backward state and vice versa. In order to achieve a smooth transition, a series of PWM pulses must be generated at the right time. For example, when the motor is moving from forward to backward state, a reverse value must be given first followed by at least three neutral values, and then continue with reverse values.

[[File:CMPE243_S20_T2_Canster_Truck_Motor2.png|thumb|center|400px| Motor Flowchart 2]]

=====LIPO Battery Voltage=====
The LIPO Battery Voltage was calculated using ADC in Burst Mode. A LIPO Hardware module was created for the same which contained two functions, <code>lipo__init</code> and <code>lipo__get_voltage</code>.

The voltage divider circuit is stepped down from 7.4V to 2.1V using 10K and 4K Resistor pair.

'''LIPO Initialization'''

The LIPO Initialization phase initializes the ADC, Enables Burst mode on the ADC pins and configures the Alternate Function Registers for the same.

'''LIPO Get Voltage'''

We read the raw ADC value from the LPC Hardware register. This value will be from 0 - 3.3V. However due to our voltage divider configuration the max voltage that we should theoretically get is 2.1V. This means that 2.1V corresponds to 7.4V of the LIPO Battery voltage.

The formula used is
<code>(raw_adc_value * MAX_LIPO_BATTERY_VOLTAGE_VALUE) / MAX_LIPO_ADC_VALUE</code>

=== Technical Challenges ===
<ol>
<li>Changing movements of the car from Forward to Backward and vice versa
If you just change the PWM value from say 16 (Forward) to 14(Backward), the DC motor will just stop and will not make wheels turn reverse. We discovered this problem quite late as during the initial testing we had always run the car from the start with either forward or reverse but never tried changing the direction during run-time.
Solution: The motor requires a series of PWM pulses which is specific to the car to transition from forward mode to reverse mode. In our case we had to give the PWM pulses in the following sequence. Suppose,
<ol>
<li> Forward (16) (callback_count=0)</li>
<li> Forward (16) (callback_count =1)</li>
<li> Reverse (14) (callback_count =2)</li>
<li> Neutral (15) (callback_count = 3)</li>
<li> Neutral (15) (callback_count = 4)</li>
<li> Neutral (15) (callback_count = 5)</li>
<li> Reverse (14) (callback_count = 6)</li>
<li> Continue reverse</li>
</ol>
Similarly, the reverse to forward can also be implemented.
<li>DC motor shooting off when there is an improper ground connection
When we connected the battery voltage circuit for reading the voltage from the battery, the motor would randomly shoot off every now and then.
Solution: Connect the voltage divider circuit to the common ground rather than taking the ground from the ESC.</li>
</ol>

<HR>
 

== '''Geological Controller''' ==

<Picture and link to Gitlab>

===Messages===
*GEO_HEARTBEAT: Used to check for MIA by other nodes. Highest priority message for GEO Node

*GEO_DEGREE: Sends the current degree relative to the North Pole computed by the Compass and the Required degree relative to the North Pole computed by Bearing Angle using the Current Coordinate and Destination Coordinate.

*GEO_DESTINATION_REACHED: Sets a flag, 0 for destination not reached and 1 for destination reached

*GEO_CURRENT_COORDINATES: Debug Message used to send the Current GPS Coordinates

*GEO_DISTANCE_FROM_DESTINATION: Debug message used to send the Distance from Destination

*CURRENT_CHECKPOINT_DBG: Debug message used to check which checkpoint is being navigated to

=== Hardware Design ===

[[File:CMPE243_S20_T2_GEO1.png|thumb|center|650px| Geological Diagram]]

=== Software Design ===
=====Overview=====
*Inside the `periodic_callback__initialize`
**Initialize the CAN BUS
**Initialize the GPS

*Inside the `periodic_callback__1hz`
**Handle all MIA (from other Nodes)
**Update GPS LED when init and in case of failure
**Compute the GEOLOGIC for Waypoints algorithm once every second (1000 ms)

*Inside the `periodic_callback__10hz`
**Handle CAN Incoming messages (Decode)
**Transmit CAN Geo messages (Encode and send)
**Compute the GPS Coordinate

=====Compass I2C Driver=====
An online datasheet resource was used to work with the Compass (https://www.robot-electronics.co.uk/htm/cmps11i2c.htm)
Initially the Compass I2C Driver was tested using the Terminal I2C Helper built by our Professor Preetpal Kang. Using this resource we were quickly able to read various I2C Registers and display it onto the terminal.

For our project the only required part of the Compass was the 16-bit Compass Bearing value (0-3599) i.e 0-359.9 degree values. These values were stored in the 2nd and 3rd register (Register 2 being the High Byte).
Once the raw data was received over I2C we could easily combine the data

<pre>
uint16_t bearing_value = (Reg2 << 8) | Reg3;
float rval = bearing_value / 10.0;
return rval;
</pre>
The returned value were transmitted to the Driver Node to compute its steering based on the required Bearing Angle.

=====GPS Initialization=====
GPS Initialization activates the Hardware GPIO (RX and TX), FreeRTOS Queue for UART Interrupts (UART Module) and Line Buffer Module to parse each GPS line.

=====GPS Data Parsing=====
The GPS Hardware module transmits an NMEA string over UART to the SJTwo Board. We read each character one by one and add it to the Line Buffer module.
Inside its computation loop, the Line Buffer module checks if a newline character has been received.
When a newline character has been received the entire string is extracted from the line buffer module and parsed according to its identifier ($GPRMC, $GPGGA) received and parsed into individual tokens.
For our purposes the $GPRMC NMEA string was the most appropriate and it helped us extract the Current Latitude Longitude as well as the Valid/Invalid tag for the Canster Truck.

=====GPS LED Indication for debugging=====

A simple module that checks for the GPRMC GPS Message and extracts the A or V valid (Tag). If $GPRMC NMEA string is valid, LED is set, else LED is reset. This gives us onsite debugging capabilities to know if GPS has locked onto a satellite signal.

=====GEO Logic Module Computation=====
The GEO Logic Module computes the Bearing Angle, Haversine Distance as well as the Waypoints algorithm.

'''Bearing Angle:'''

<code>
θ = atan2( sin Δλ ⋅ cos φ2 , cos φ1 ⋅ sin φ2 − sin φ1 ⋅ cos φ2 ⋅ cos Δλ )
</code>

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

Since atan2 returns values in the range -π ... +π (that is, -180° ... +180°), to normalize the result to a compass bearing (in the range 0° ... 360°, with −ve values transformed into the range 180° ... 360°), convert to degrees and then use (θ+360) % 360, where % is (floating point) modulo.
For final bearing, simply take the initial bearing from the endpoint to the start point and reverse it (using θ = (θ+180) % 360).

The above article reference gives us the required bearing angle that our car must align itself to, to reach a particular destination coordinate from its current coordinate.
The Steering of the Canster Truck depends on the above-computed angle values.

'''Haversine Distance Formula:'''

This uses the ‘haversine’ formula to calculate the great-circle distance between two points – that is, the shortest distance over the earth’s surface – giving an ‘as-the-crow-flies’ distance between the points (ignoring any hills they fly over, of course!).

<code>
a = sin²(Δφ/2) + cos φ1 ⋅ cos φ2 ⋅ sin²(Δλ/2)

c = 2 ⋅ atan2( √a, √(1−a) )

d = R ⋅ c
</code>

where φ is latitude, λ is longitude, R is earth’s radius (mean radius = 6,371km);
note that angles need to be in radians to pass to trig functions!

The above formula is used to calculate the distance between the source coordinate (received via GPS) and the destination coordinate.
Later this was used to compute the distance between source coordinate and each individual checkpoint to traverse the shortest distance.

'''Waypoints Algorithm:'''

The Waypoints algorithm that was chosen was a slightly modified version of Djikstra’s Algorithm.
3 values were calculated before the final computation
- Distance between source and final destination (DISTsd)
- Distance between source and each individual checkpoint (DISTsc)
- Distance between each individual checkpoint and the final destination. (DISTcd)
If DISTsd was lesser than DISTcd, this checkpoint was discarded (we continue in the loop). Since we would be moving in the opposite direction, rather than towards the final destination.
If DISTsd was greater than DISTcd, then we checked the nearest checkpoint to the source.
The minimum value was set initial that was equal to DISTsd.
If DISTsc was lesser than the minimum value stored, DISTsc would become the new minimum value, and the checkpoint index and coordinates would be appropriately stored and returned from the function.
In this way we would navigate to the nearest checkpoint from the source, while also making sure NOT to travel in the opposite direction.
This logic is recomputed only when we reach the checkpoint selected and the algorithm runs again to find the next checkpoint that we need to navigate to.

=====CAN Decode Destination Coordinates=====
Destination Coordinates are received from the Bridge and Sensor Node and transmitted over the CAN Bus. The value is decoded and stored in the GEO Logic Module.
This is a very important value since our entire GEO Logic calculations are based on the Destination Coordinate.

=====CAN Encode and Send=====

The main messages that were transmitter are
#Geo Degree
#Geo Destination Reached
#Distance from Destination Debug and Checkpoint Index debug

'''Geo Degree Computation as per Waypoints Algorithm:'''

Geo Degree was computed as per the current coordinates and the most recently computed checkpoint coordinates. This bearing angle calculation w.r.t computed checkpoint would continue till we do not reach that particular checkpoint.
Once we reach the computed checkpoint, Waypoint algorithm is recomputed as per the process mentioned above and the algorithm runs again.

'''Geo Destination Reached:'''

An Area of around 4 meters was set around the destination coordinate to check if the destination had been reached.
This measurement was taken into consideration to allow for the loss in precision when transmitting data over CAN as well as any irregularities that might occur when getting values from the GPS.
Having an area of 4 meters was very accurate for all of our test runs.

'''Geo Distance from Destination Debug and Checkpoint Index Debug:'''

Getting debug information was very critical to speed up our development process. In this case we could actively see if our algorithm worked properly.
The Geo Distance from Destination was used to see if we were moving closer to our destination or veering further away from it.
The Checkpoint Index was used to see which checkpoint index we were traveling to. By knowing the placements of the Individual checkpoints we could manually as well as programmatically (via Android application) verify the working of our Canster Truck.

=== Technical Challenges ===
#DBC Challenge for GEO Coordinates -> Could not encode more than 5-6 decimal places at a time, on later investigation we found that the 10000 is an int value, however 100000 overflows the int value.
#Creating an efficient algorithm for Waypoints, O(n) complexity.
#Getting appropriate fixes for GPS when not in a completely open space.
#GPS used to fluctuate or stop giving values when Battery voltage went below a particular threshold. Always supply 3.3V constantly at a good amperage.

<HR>
 

== '''Sensor [Bridge and Sensor Controller]''' ==
<Picture and link to Gitlab>

==='''Ultrasonic Sensor'''===
====Hardware Design====
This sensor uses an ultrasonic beam to measure the distances. Based on the time taken between when the beam is sent and received back to the sensor, the distance is calculated in the node.
Apart from 5v and GND, this sensor has 2 pins ECHO and TRIG which are interfaced with the SJ-Two board via GPIO.

[[File:CMPE243_S20_T2_CansterTruck_ultrasonic_sensor.jpg|thumb|center|300px| Ultrasonic Sensor Diagram]]

====Software Design====
* Init the GPIO pin connected to TRIG of the sensor as output and for ECHO as an input port.
* Attach the interrupt on the ECHO input port.
* Store the system_clock_count before setting the trigger pulse and then set the pulse. Also keep monitoring the input port.
* Take the system_clock_count at the instant of receiving the interrupt.
Distance = (system_clock_count_at_trig - system_clock_count_after_at_echo) / 57.14

==='''Lidar Sensor'''===
====Hardware Design====
The RPLidar sensor can be powered from a 5-volt source and uses UART communication to receive commands and transmit data. It has seven pins to interface with. Two sets of the pins (four total) are for power and ground. The remaining three are for UART receive and transmit, and for making the lidar’s motor spin.

[[File:CMPE243_S20_T2_Canster_Truck_RPLidar_A1.JPG|thumb|center|300px| RPLidar A1]]

====Software Design====
In terms of the lidar, the SJ2 initializes GPIO, UART, and memory for storing the measurement values. After initialization, the command to begin scanning is sent. Here, we wait for the lidar to send a response packet, letting the host (SJ2 board) know it received the command. The response packet the lidar sends will be 7 bytes. If the correct 7 bytes are not received, the command will be sent again.

[[File:CMPE243_S20_T2_Canster Truck_Lidar_flow.jpeg|thumb|center|200px| Lidar Flow]]

Following the response packet, the lidar begins sending 5-byte measurement data. Each sample contains a distance measurement (in millimeters) and the angle (with respect to the lidar) in which it was taken. The data packet structure is shown in the following figure. In addition to containing the distance and angle, the packet includes a quality value, to indicate the reliability of the measurement, and three check bits (S, ~S, and C). As the data is received via UART, we wait until we have 5 bytes before continuing to process. Before processing the 5 bytes after receiving them, the check bits are confirmed to be correct. If they are incorrect, it will not be processed and we will wait for another sample to be received.

[[File:CMPE243_S20_T2_Canster Truck_DataPacketStructure.JPG|thumb|center|200px| Data Packet Structure]]

In the case the sample is correct, each measurement value that is in a direction of interest will be placed in an array designated to one of four directions (left, right, front, rear). Each of these directions have their own sector in the lidar’s 360-degree view.
*Right sector: 11°-30°
*Rear sector: 170°-190°
*Left sector: 330°-349°
*Front sector: 350°-370° (or 10°)

The arrays mentioned will hold roughly 20 measurements, which are every degree in the sector. In the event, objects are too far to measure, the lidar will report 0 mm. distance. Since there is no measurable obstacle, a “large” distance value of 3000 mm. is placed in the array. The smallest distance value will be taken from each array and reported to the driver node for obstacle avoidance.

=== Technical Challenges ===
====Ultrasonic====
====Lidar====
*'''Datasheet not 100% clear:''' The correct datasheet for the was a bit difficult to obtain, and the manufacturer needed to be contacted. The first document found online was high level and general information about the sensor, but the manufacturer did provide another document that contained the information of the commands and responses to and from the lidar, and their packet structure. The documents did not clearly state the angles with respect to the lidar are fixed, which left me wondering if the lidar will think the direction it is facing when powered on will become the new “zeroth” angle.

*'''UART Buffer Overflow:''' When first interfacing with the sensor, the incoming bytes of the lidar were printed on to the terminal to make sure there was a response and to make sense of the information. Since the command we sent results in 5 bytes of data per measurement samples from the lidar and the lidar measured 2000 times per second, there are will be roughly 10k Bytes per second of data incoming that need to be handled continuously. With an improperly sized UART buffer and print statements it is guaranteed to occur, making the lidar data look like random values.

*'''Proper Parsing of Measurement Data:''' After sending a command to the lidar, the sensor will send a response packet, followed by the measurement data. The initial response from the lidar is a 7-byte packet, followed by continuous 5-byte measurement samples. I needed to make sure however I handled the response would be independent of how the measurement is handled, so as not to create a potential unwanted offset when receiving measurements.

*'''Object Detection with Received Data:''' Once proper communication was set up with the lidar and measurement data was getting decoded, there needed to be a way to measure when obstacles were present. If ~360 measurements are handled entirely independently from one another, it could become a complex and confusing code. To achieve a simple approach, four sectors about 20 degrees in size were used to represent the front, left, right, and rear directions.

*'''Bugs in Code:''' When first implementing the code, there were a few bugs from typos, incorrect numbers, and some faulty logic that were found with the use of unit testing. Unit testing helped find these issues and verified the logic was correct, and I would say gave me 90% confidence in my lidar handling.

<HR>
 

== '''Bridge [Bridge and Sensor Controller]'''==
<Picture and link to Gitlab>

Bridge functionality of the Bridge and Sensor Controller is to establish wireless communication between the SJ-2 Board and the android mobile device using the HC-05 Bluetooth module. The Bridge controller will be receiving start command with destination GEO coordinates and stop command. The Bridge controller will be transmitting the required sensor data and debug information to be displayed on the android application.

[[File:CMPE243_S20_T2_BRIDGE.png|thumb|center|500px| Bridge Diagram]]

===Bluetooth===

==== Software Design ====
<ol>
<li> Low-Level Layer
In this layer, similar to the GPS the UART GPIO was initialized (RX, TX), FreeRTOS Queue was initialized for UART Interrupts and the line buffer module was initialized to parse strings.

Two basic functions '''bt__read''' and '''bt__write''' were implemented.
As the name suggested, '''bt__write''' took a string as its input parameter and transmitted that data to the Android application. '''bt__read''' stored the incoming characters into the line buffer, parsed the line received into its identifier and tokens, and invoked a callback function.

Since this was a low-level layer the User would not be directly invoking this library. Instead a '''Bluetooth Wrapper''' module was created which would be invoked and used by the user.
</li>

<li>Application Layer

The Bluetooth Wrapper module had the appropriate '''read_once''' and '''write_once''' functions.

The `read_once` function internally just called the '''bt__read''' function. All of the decodings was done inside the Callback Function.
To get the Destination coordinate the string received from the Android Application was in the form of
<pre>$loc,<destination_latitude>,<destination_longitude>.</pre>
Upon receiving this data we parsed the destination_latitude and destination_longitude, which could later be accessed using getters.
We also set a start flag to notify the Driver Node that destination has been received and we can start steering towards our checkpoints.
Another command implemented was the stop command.
<pre>$stop</pre>
This was used to send a stop flag to the Driver node.

The '''write_once''' function used the getter methods from each CAN Decode message and update its internal state variables. A CSV String was created using the <pre>$canster</pre> identifier and various debugging points were appended to this message using a comma.
On the Android application side this CSV string was tokenized and displayed onto the Application Debug screen appropriately.
</li>
</ol>

==== Technical Challenges ====

<List of problems and their detailed resolutions>

<HR>
 

== '''Driver [Driver and LCD Controller]''' ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===

[[File:CMPE243_S20_T2_Canster Truck_Driver_Flowchart.png|thumb|center|750px|Driver Flowchart]]

The above block diagram explains the process flow of obstacle detection for the car. The LIDAR detects
the obstacle and depending on the distance of obstacle the car takes a slight right and slight left or a
hard right and hard left. The state of the car also depends on the value of the LIDAR and ultrasonic sensor.
The loose ends of the LIDAR for the reverse condition are checked by the ultrasonic sensors. The
The ultrasonic sensor works on the principle of trigger and echo and can detect the obstacles very close by.
The range of the Ultrasonic sensor is lower than the LIDAR. Finally, if no obstacle is detected the car goes
straight until the destination is reached. The speed of the car is also various when an obstacle is detected to
avoid the crash and the car’s smooth transition from one state to another. The key to the android
application controls the start and stop the process of the car. If the key is not pressed, then the stays in the

neutral state. The speed of the car is controlled by the changing duty cycle of the input voltage. There
are seven-speed levels in which the motor can run on. These speed levels are Forward Slow, Medium,
Fast, Reverse Slow, Medium, Fast, and Neutral. The Neutral is the stop condition with a 0% duty cycle.

=== Technical Challenges ===

< List of problems and their detailed resolutions>

<HR>
 

== '''LCD [Driver and LCD Controller]''' ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
The GLCD used was created by 4DSystems, using their IDE a UI was created. Each UI component could be controlled by sending UART data targeted at the widget address.
The best part about this GLCD was that we had a lot of interactive widgets to display debugging information in real-time.
The GLCD code was divided into 3 parts:
<ol>
<li>'''Low-Level Initialization'''
Initialize the low-level hardware interfaces to send and receive data from the GLCD.
Similar to the GPS and Bluetooth, The UART GPIO was initialized (RX, TX), FreeRTOS Queue was initialized for UART Interrupt and line buffer was used to get a stream of data for parsing.

Low-level '''read''' and '''write''' commands were used as per the working of the GLCD Module.
When Reading data pertaining to a widget on the GLCD we would need to send a particular response packet.
<pre>
void lcd__read(lcd_object_e object_id, uint8_t object_index, uint8_t *response, uint16_t *response_data) {

uint8_t checksum = READ_OBJ ^ object_id ^ object_index;
uint8_t buffer[] = {READ_OBJ, object_id, object_index, checksum};

lcd__write_data(buffer, sizeof(buffer) / sizeof(uint8_t));
lcd__read_response_id(response);
lcd__read_response_data(response_data);
}
</pre>

The response_data returned contains the Widget ID as well as the current value stored on that widget.

When Writing data pertaining to a widget on a GLCD the process is similar to the above mentioned code.
<pre>
void lcd__write(lcd_object_e object_id, uint8_t object_index, uint8_t msb, uint8_t lsb, uint8_t *response) {
uint8_t checksum = WRITE_OBJ ^ object_id ^ object_index ^ msb ^ lsb;
uint8_t buffer[] = {WRITE_OBJ, object_id, object_index, msb, lsb, checksum};

lcd__write_data(buffer, sizeof(buffer) / sizeof(uint8_t));
lcd__read_response_id(response);
}
</pre>

However in this case we receive only an ACK or NACK from the system. ACK would mean that the write to GLCD widget was successful and the widget now stored appropriate values. NACK would mean that a particular error has occurred. The errors could be regarding baud rate, incorrect bit format, incorrect index values, etc.
</li>
<li>'''GLCD Wrapper for Widgets'''
The above low-level code had generic read and write functions. However for our UI we were only using 3 Widgets. All of which had '''different Indexes''' and '''Widget IDs'''.
Therefore a very simple library was created to easily interface with those widgets
<pre>
bool lcd_wrapper__read_led(uint8_t index);
uint16_t lcd_wrapper__read_meter(uint8_t index);
uint16_t lcd_wrapper__read_leddigit(uint8_t index);

bool lcd_wrapper__write_led(uint8_t index, bool value);
bool lcd_wrapper__write_meter(uint8_t index, uint16_t value);
bool lcd_wrapper__write_leddigit(uint8_t index, uint16_t value);
</pre>

The above code is self-explanatory read and write functions for '''LED''', '''METER''', and '''LED DIGIT'''.
</li>
<li>'''GLCD UI'''
Now that we had our low level and Widget wrapper working properly, we wanted to create our Dynamic UI as well. The code would need to be robust enough to handle any UI that we create on the GLCD which could be reflected equivalently in our C Code.

<pre>
static void lcd_ui__update_ui(void) {

lcd_wrapper__write_led(LCD_LED_DRIVER_MIA_INDEX, driver_mia_led);
lcd_wrapper__write_led(LCD_LED_SENSOR_MIA_INDEX, sensor_mia_led);
lcd_wrapper__write_led(LCD_LED_GEO_MIA_INDEX, geo_mia_led);
lcd_wrapper__write_led(LCD_LED_MOTOR_MIA_INDEX, motor_mia_led);

// kph is always in the range of 0 - 10
lcd_wrapper__write_meter(LCD_METER_KPH_INDEX, kph_meter % 11);

// These will be in the Range of 0-99
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_RPM_INDEX, rpm_leddigit % 100);
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_CURRENTDEGREE_INDEX, cdegree_leddigit % 100);
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_REQUIREDDEGREE_INDEX, rdegree_leddigit % 100);
}
</pre>

As we can see the `lcd_ui__update_ui` function was called periodically inside the 1Hz function. It updated the screen in real time based on the static values that were stored AND updated inside the LCD UI module.
The Constant INDEX values stored were directly mapped onto the Index values were received from the 4DWorkshop UI Software.
</li>
</ol>

=== Technical Challenges ===

< List of problems and their detailed resolutions>

<HR>
 

== '''Android Application''' ==
[https://gitlab.com/akhilcherukuri/can-ster_truck_application Gitlab]
=== Software Design ===

<div><ul>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android1.jpg|thumb|none|250px|Splash Screen]]</li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android2.jpg|thumb|none|250px|Main Activity Screen]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android3.jpg|thumb|none|250px|Map Activity Screen]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android4.jpg|thumb|none|250px|Info Activity Screen 1]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android5.jpg|thumb|none|250px|Info Activity Screen 1]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android6.jpg |thumb|none|250px|Debug Activity Screen]]</li>
</ul></div>

The application consists of a total of 5 Activities:

*'''Main Activity:'''
**This is the app launch display screen
**It will check for all the required permission onStart().
**Has search button for connecting from a paired device list view
**Once device is clicked, an intent will start the Map Activity
*'''Map Activity:'''
** For this requirement we are using the Google Maps Fragment, for the map fragment to function we must request an API key from Google and set the key in the manifest of the application.
** Destination marker(Red Marker) is set using setOnMapClickListener to which the car will navigate to, the destination can be changed by clicking elsewhere on the Map Fragment. The marker can be removed using setOnMarkerClickListener.
** When the start button is pressed, the start command identifier along with destination latitude and longitude is sent to the car via the write thread. A background thread is started along with it to indicate the current car's position(Green Marker) along with a plotline between the current position and destination.
** When the stop button is pressed, the stop command identifier is sent to the car, to stop and turn off the car.
*'''Info Activity:'''
** Messages from Geological, Driver, Motor coming from CAN bus are decoded by the Sensor and Bridge controller and sent to the Android application as a string.
** The received string is parsed and categorizes the data to store it in the required textView to be displayed.
** Bluetooth status, Lidar Values, Ultrasonic Sensor Values, Motor Speed, Motor RPM, Motor PWM, Cars' current location, Compass Heading, Distance till Destination, Checkpoint Index is displayed. This was useful for debugging purposes and allowed us to avoid scanning the mounted LCD or CAN Busmaster on PC during drives.
*'''Debug Activity:'''
**The main function of this activity is to check all RAW RX and RAW TX messages and create a log of all the data received and sent.
*'''Bluetooth Connection Service Activity''' :
**This is the background activity that handles all the threads required for transmission and receiving data using Bluetooth connections. It has 3 running threads which is called inside other activities using a handler:
** Accept Thread - Listens to BluetoothServerSocket using listenUsingRfcommWithServiceRecord. In order for the RF communication socket to connect to the HC-05, we used the following UUID: 00001101-0000-1000-8000-00805F9B34FB. This is a generic SSP Bluetooth UUID that enables the socket to directly connected to HC-05 and maintain the connection.
** Connect Thread - Creates a Bluetooth socket using createRfcommSocketToServiceRecord
** Connected Thread - Creates socket.getInputStream(); and socket.getOutputStream(); when bytes are available in input stream it will read them into a buffer.
***All messages for activities are done by Handler mHandler.obtainMessage(); mHandler.sendMessage();

*'''Receieved string''':
** A String is sent to the Bluetooth app from HC-05 and when it receives a string with identifier "$canster", the message is prased accordingly by using the string delimiter ',' and is ended by the newline character '\n' which will remove the data from StringBuffer.
** Example: $canster,37.339334,-121.881123,37.338713,-121.880685,10.123,20.133,30.123,10.5,88.1,99.2,-2,1,44,7,11,22,33,-3,23\n

[[File:CMPE243_S20_T2_BLUETOOTHFLOWCHART.png|thumb|center|650px| Android Application Flowchart]]

=== Technical Challenges ===

<HR>
 

== '''Mangaement''' ==
===Team Management ===
===Git Management===

Git Management amongst 6 team members was definitely a very challenging task. Depending on our initial design we could’ve had a lot of merge conflicts. However those risks were mitigated by spending a LOT of time in the initial stages to decide our pipeline and structure.

<li>There are certain components in our system that were COMMON. For example the CAN initialization, communication and decodes were all similar for the most part between all the 4 Controllers. The utility modules used were also similar in nature</li>
<li>Thus we made a common branch that contained the templates for CAN Nodes (not Controllers), Hardware code and Utility functions.
<ol>
<li>Later this common branch was forked into an individual Controller specific branch (SENSOR, GEO, MOTOR or DRIVER).</li>
<li>Only the Logic folder contained Controller specific code, specific to that controller.</li>
</ol>
<li>This gave us a lot of flexibility since all the team members had similar APIs to work with on all 4 branches. This promoted easy understanding and learning.
<ol>
<li>Many team members frequently worked on 2 or more controllers at a time where can messages were concerned. Having a APIs also meant that just the can_handler needed to be updated regularly followed by the equivalent logic code. </li>
<li>Inside the logic folder, getters to the can node modules were frequently used.</li></ol>
<pre>
├───can_module
│ ├───can_bus_initializer
│ ├───can_constants
│ ├───can_driver_node
│ ├───can_geo_node
│ ├───can_handler
│ ├───can_motor_node
│ ├───can_sensor_node
│ └───test
├───hardware
│ ├───bt
│ ├───compass
│ ├───gps
│ ├───lcd
│ ├───test
│ └───ultrasonic
├───logic
│ ├───driver_obstacle
│ ├───driver_state
│ ├───geo_logic
│ └───test
├───periodics
│ └───test
└───utility
├───line_buffer
└───test
</pre>

'''Challenges'''
<li>It was initially a bit of a learning curve to understand the flow of the repository</li>
<li>When using a git management system with different versions in each branch it became very tough when the number of branches suddenly exploded in size. A lot of relevant code was stuck in a lot of different branches.
<ol>
<li>This happened mainly due to assignment submissions and unclosed MRs that eventually became stale.</li>
<li>Our strategy was to abandon these MRs and keep forking from these branches without merging it back into its final controller branch.</li>
<li>The latest branches that were kept were aptly named `<controller>_bleeding_edge_dev` branches since they were never merged back from where they were forked.</li>
</ol>
<li>Since a lot of our code also depended on the DBC autogenerated code, we could not suddenly change the DBC Message names once they were established since it caused a change in the Struct name that was generated and used.
<ol>
<li>Our solution to this was to keep everything backward compatible. We added new function names without deleting old DBC messages.</li>
<li>In certain places where we wanted to modify a function name it was done one by one so that a lot of the code is not broken at one time.</li>
</ol>
<li>Common Branches eventually became stale as our progress continued on the bleeding edge branches
<ol>
<li>For example certain GPS features needed to be added which were done on the GEO_bleeding_edge_dev branch but never pushed or cherry-picked back into the COMMON branch.</li>
<li>This was a similar issue to our 2nd point but manageable since the goal of the COMMON branch was to provide a template for further work and nothing more.</li>
<li>At the end of the day each controller is its own Individual Project and while the messages between them are same. The Hardware code does not need to be same.</li>
<li>This also prompted team-members to ask if we could delete unused hardware or logic file code (which wasn’t being used and was imported from the template). This was also fine and can be done during cleanup stage. However we eventually got used to the Modular system of our project so much so that we did not worry about the additional modules that were present in each branched controller project.</li>
</ol>

<HR>
 

== '''Conclusion''' ==
CMPE243 gives one of the best experiences one could ever get in their academic life. The course is designed to give an insight into how the industry functions and enhances both technical and management skills. Apart from learning how to work and implement application of CAN protocol, one can get a hands-on experience with version control, unit-testing and software design. Overall it was a very great journey.

=== Project Video ===

=== Project Source Code ===

=== Advise for Future Students ===
'''GENERAL:'''
* Form your team and start the project as early as you can.
* Clearly discuss what role each individual should do and ensure that progress is regularly tracked so that the team doesn't fall back on any schedule.
* Since lot of code and hardware integration is involved with this project, make sure testing is thoroughly and periodically done and make note of all the issues found.
'''HARDWARE:'''
* Decide on how you would power up the peripherals. We had issues with Bluetooth (not connecting), GPS (lock not happening) and LIDAR (giving incorrect values). After lot of cycles of hardware and software debugging, we found that the issue was with power. Choose wisely as to which peripherals must be connected to which power bank.
* PCB design is time consuming as there is a lot of hardware components involved and a huge responsibility falls on the designer to know the about each component. Coordinating with multiple team members and verifying with them if their respective hardware is correct takes a lot of time. So start well ahead.
* Make sure to expose some extra GPIO and GND pins for future use.
'''MOTOR:'''
*You can use the LiPo battery to power the RPM and servo motor instead of using a separate power source. Use Vout from the ESC to get 6V.
*Start the PID control calibration early on as you will need to do extensive testing to get it working.

=== Acknowledgement ===
<HR>
Firstly we would like to express our gratitude to Professor Preetpal Kang for his guidance throughout the semester and providing us with this opportunity. We would also like to thank the ISA members Vignesh Kumar Venkateshwar and Aakash Vrajlal Chitroda for being available whenever in need and guiding us to complete the project.

== '''References''' ==

===Motor Controller===
===Geological Controller===
* Movable Scripts: [https://www.movable-type.co.uk/scripts/latlong.html Calculate distance, bearing and more between Latitude/Longitude points]
* CMPS11:[https://www.robot-electronics.co.uk/htm/cmps11i2c.htm I2C Configuration]

===Bridge and Sensor Controller===
===Driver and LCD Controller===
*LCD Software: [https://4dsystems.com.au/ulcd-32ptu 4Dsystems]
===Android===
*Youtube Channel: [https://www.youtube.com/channel/UCoNZZLhPuuRteu02rh7bzsw Coding with Mitch]
*Android Developers: [https://developer.android.com/guide/topics/connectivity/bluetooth Website][https://github.com/googlearchive/android-BluetoothChat Github]
*Udemy Course: [https://www.udemy.com/course/the-complete-android-oreo-developer-course/ Complete Android Oreo Developer Course]
===PCB Design===
*EDC Tool: [https://easyeda.com/ EasyEDA]

S20: Canster Truck

2020-05-22T05:36:17Z

Proj user22: /* Motor Controller */

[[File:CMPE243_S20_T2_Canster_Truck_Logo.png|thumb|455px|caption|right|CAN-STER TRUCK LOGO]]

== '''Abstract''' ==
'''The Canster Truck Project is an autonomous RC car with CAN Bus interfaced controllers. The development of the RC car's subsystem modules (Interfacing of Ultrasonic Sensor, LIDAR, Bluetooth, GPS, Compass and CAN modules) was divided among six team members. The aim of the project is to develop an autonomous RC Car which can navigate from one source location to the selected destination on the app by avoiding obstacles in its path using sensors. Waypoints algorithm is used as the path finding technique.'''

 

== '''Introduction and Objectives''' ==

'''The project was divided into 7 modules:'''

* '''Bridge and Sensor Controller'''
* '''Motor Controller'''
* '''Geological Controller'''
* '''Driver and LCD Controller'''
* '''Hardware Integration'''
* '''Android Application'''
* '''Testing & Code Review'''

'''RC Car Objectives'''
'''1. Driver and LCD Controller''' - Handles algorithms for obstacle avoidance, route maneuvering, and waypoints
'''2. Geological Controller''' - Recieves coordinates from GPS and Heading from Compass for navigation
'''3. Motor Controller''' - Controls movements of the RC Car
'''4. Bridge and Sensor Controller''' - Detects surrounding objects and interfaces android application to controller via bluetooth
'''Team Objectives'''

[[File:CMPE243_S20_T2_High_Level_System_Diagram.png|thumb|center|800px| High Level System Diagram]]

 

== '''Team Members and Responsibilities''' ==

'''Gitlab Project Link''' - [https://gitlab.com/coder137/can-ster_truck '''Canster Truck''']
 

*'''Niket Naidu''' [https://www.linkedin.com/in/niket-naidu-30090a134/ LinkedIn] [https://gitlab.com/coder137 Gitlab]
** '''Geological Controller''' : Waypoint Algorithm, Haversine and Bearing Angle logic
** '''Driver and LCD Controller''' : GLCD
** '''Bridge and Sensor Controller''' : Bluetooth
** '''Testing & Code Review'''

*'''Ganesh Ram Pamadi''' [https://www.linkedin.com/in/ganeshram93/ LinkedIn] [https://gitlab.com/ganeshram2493 Gitlab]
** '''Hardware Integration'''
** '''Testing & Code Review'''
** '''Driver Controller'''
** '''Motor Controller'''

*'''Nikhil Pabbisetty''' [https://www.linkedin.com/in/nikhilpabbisetty/ LinkedIn] [https://gitlab.com/nikhilpeoria Gitlab]
** '''Bridge and Sensor Controller'''
** '''Motor Controller'''

*'''Akhil Cherukuri''' [https://www.linkedin.com/in/akhilcherukuri/ LinkedIn] [https://gitlab.com/akhilcherukuri Gitlab] [https://github.com/akhilcherukuri Github]
** '''Android Application'''
** '''Bridge and Sensor Controller'''

*'''Ashish Anant Ladage''' [https://www.linkedin.com/in/ashish-anant-ladage-7bb3a214b/ LinkedIn] [https://gitlab.com/ashishladage1 Gitlab]
** '''Driver and LCD Controller'''
** '''Hardware Integration'''
** '''Motor Controller'''

*'''Jesus De Haro De Reza''' [https://www.linkedin.com/in/jesus-de-haro-66342424/ LinkedIn] [https://gitlab.com/deharo27 Gitlab]
** '''Bridge and Sensor Controller'''
** '''Motor Controller'''

 

== '''Administrative Responsibilities''' ==
* '''Team Lead''' - [https://www.linkedin.com/in/niket-naidu-30090a134/ '''Niket Naidu''']
* '''Git Repository Manager''' - [https://www.linkedin.com/in/niket-naidu-30090a134/ '''Niket Naidu''']
* '''Bill Of Materials Manager''' - [https://www.linkedin.com/in/akhilcherukuri '''Akhil Cherukuri''']
* '''Wiki Report Manager''' - [https://www.linkedin.com/in/akhilcherukuri '''Akhil Cherukuri''']

 

== '''Schedule''' ==

{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-

! scope="row"| '''1'''
| style="text-align:center;" |'''02/11/2020'''
| style="text-align:center;" |'''02/17/2020'''
|
*'''Form teams and decide group name'''
*'''Review past projects'''
*'''Slack: Create project group and invite Preet'''
*'''GitLab: Create project groups repository'''
*'''Analysis of component required'''

|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''2'''
| style="text-align:center;" |'''02/18/2020'''
| style="text-align:center;" |'''02/24/2020'''
|
*'''Study CAN Communication'''
*'''Create Bill of Materials'''
*'''Order RC Car'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''3'''
| style="text-align:center;" |'''02/25/2020'''
| style="text-align:center;" |'''03/02/2020'''
|
*'''Setup team finance management using Splitwise application'''
*'''Complete Bill of Materials'''
*'''Order all other required components'''
*'''Wikipedia: Setup project report template'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''4'''
| style="text-align:center;" |'''03/03/2020'''
| style="text-align:center;" |'''03/09/2020'''
|
*'''Read the respective datasheets and manuals for each component'''
*'''Test each component for working conditions'''
|
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''5'''
| style="text-align:center;" |'''03/10/2020'''
| style="text-align:center;" |'''03/16/2020'''
|
*'''Assign team responsibilities and roles'''
*'''Setup team project management environment (ClickUp)'''
*'''Define CAN DBC'''
*'''Research GPS antennas and order'''
*'''Android: Environmental setup of Android Studio and enable version control'''
*'''Hardware : Decide PCB editing software (easyEDA)'''
*'''Hardware : Draft schematic for required PCB design'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''6'''
| style="text-align:center;" |'''03/17/2020'''
| style="text-align:center;" |'''03/23/2020'''
|
*'''Hardware : Create model of PCB''' 
*'''Android: Add a Button for changing bluetooth connection status in the application''' 
*'''Geological: Interface Compass module with SJ-2 board using I2C interface''' 
*'''Geological: Interface GPS module with SJ-2 board using the UART interface''' 
*'''Geological: Parse raw data to get meaningful values for GPS and Compass''' 
*'''Sensor: Interface and check the functionality of ultrasonic sensors to the SJ-2 board''' 
*'''Motor: Interface of Servo & DC motor to the SJ-2 board and check for basic functionality''' 
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''7'''
| style="text-align:center;" |'''03/24/2020'''
| style="text-align:center;" |'''03/30/2020'''
|
*'''Hardware : Finalize components placement on PCB.''' 
*'''Motor: Add PWM functionality and test the code on DC and servo motors''' 
*'''Sensor: Interface and check and study the output readings of Lidar sensor with SJ-2 board over UART''' 
*'''LCD Display: Explore UI designing of LCD''' 
*'''Hardware: Finalize on optimal ultrasonic sensor placements''' 
*'''Android: Initiate Bluetooth communication and show staus via text view''' 
*'''Wikipedia: Establish final wiki schedule'''
*'''Complete CAN communication format for each controller and link DBC file to the Wiki'''
*'''Complete high-level system block diagram'''
*'''Complete unit-level block diagrams'''
*'''Bridge: Interface HC-5 bluetooth module with Sj-2 board using serial communicaton'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''8'''
| style="text-align:center;" |'''03/31/2020'''
| style="text-align:center;" |'''04/06/2020'''
|
*'''Hardware: Analyze PCB model and order PCB Circuit board''' 
*'''Android: Initiate Bluetooth communication and send "Hello World".''' 
*'''Wikipedia: Start adding information/images/diagrams to the relevant sections'''
*'''Motor: Configure ESC for correct speed outcome according to frequency & PWM values''' 
*'''Motor: Finish RPM sensor hardware and software implementation and integration''' 
*'''Sensor: Read output from Lidar and setup structure for outputting for DBC''' 
*'''Geological: Implement waypoints algorithm''' 
*'''Driver: Implement obstacle avoidance algorithm''' 
*'''Bridge: Pass data such as "Hello World" from HC-05 bluetooth module to bluetooth terminal android application'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''9'''
| style="text-align:center;" |'''04/07/2020'''
| style="text-align:center;" |'''04/13/2020'''
|
*'''Hardware: Remove Unused parts from RC Car''' 
*'''Hardware: Mount PCB and 3D Parts''' 
*'''Motor: Decide different cut-off values from sensor to command right /slight right/ straight/ slight left/ left to motor.''' 
*'''Android: Embed Google Maps API for setting the car's destination.''' 
*'''LCD: Work to show RC cars live status information(battery level, current speed, long, lat, bearing, sensor data, etc)''' 
*'''Driver: Test obstacle avoidance algorithm and fine-tune sensor readings''' 
*'''Geological: Test checkpoint algorithm''' 
*'''Bridge: Establish two way communication between android application and bluetooth module''' 
*'''Update Bill of Materials for miscellaneous hardware'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''10'''
| style="text-align:center;" |'''04/14/2020'''
| style="text-align:center;" |'''04/20/2020'''
|
*'''Hardware: Integrate all hardware modules''' 
*'''LCD: Testing & Validation of the LCD UI and display vehicle status information''' 
*'''Android: Send car location to the app and checkpoints received to Geo module''' 
*'''Motor: Optimize PID control by accelerating/decelerating as instructed by Driver''' 
*'''Bridge: Configure HC-05 for auto reconnection if bluetooth communication disconnects''' 
*'''Add multiple debug messages and transmit on CAN'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''11'''
| style="text-align:center;" |'''04/21/2020'''
| style="text-align:center;" |'''04/27/2020'''
|
*'''Android: Send additional vehicle status information from RC car to the Application for display''' 
*'''Android: Finalize User Interface Design and Icon''' 
*'''Continuously test the whole system and handling of corner cases (outside).'''
*'''Finalize RC Car For Project Proto 1'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''12'''
| style="text-align:center;" |'''04/28/2020'''
| style="text-align:center;" |'''05/04/2020'''
|
*'''Gitlab: Push final code'''
*April 28th: Project Proto 1
*'''Finalize RC Car for Project Demo'''
*May 1st: Project Presentation
*'''Finalize RC Car for Project Proto 2'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''13'''
| style="text-align:center;" |'''05/05/2020'''
| style="text-align:center;" |'''05/21/2020'''
|
* '''Complete Individual Contribution Peer Grading'''
* '''Review and Complete Wiki Project Page'''
|
*'''Completed'''
*'''In Progress'''
|-
|}

 

== '''Bill Of Materials''' ==
{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Item#
! scope="col"| Part Description
! scope="col"| Part Model & Vendor
! scope="col"| Quantity
! scope="col"| Cost in USD
|-
! scope="row"| 1
| '''Microcontroller Boards'''
| SJ2 Boards (Purchased from Preet Kang)
| 4
| $200.00
|-
! scope="row"| 2
| '''CAN Transceivers'''
| [https://www.waveshare.com/sn65hvd230-can-board.htm Waveshare SN65HVD230]
| 12
| $54.48
|-
! scope="row"| 3
| '''RC Car'''
| [https://www.amazon.com/Traxxas-Slash-Course-2-4GHZ-Vehicle/dp/B01DU474B0/ref=sr_1_3?ie=UTF8&qid=1474747759&sr=8-3&keywords=Traxxas+1%2F10+slash+2wd Traxxas 2WD RTR with 2.4Ghz Radio]
| 1
| $260.00
|-
! scope="row"| 4
| '''Lithium-Ion Battery'''
| [https://www.rcsuperstore.com/traxxas-7600mah-2s-7-4v-25c-id-lipo-battery-pack/ Traxxas 7600mAh 2S 7.4V 25C iD LiPo Battery Pack]
| 1
| $75.00
|-
! scope="row"| 5
| '''Lithium-Ion Battery Charger'''
| [https://www.amazon.com/Traxxas-2970-EZ-Peak-Charger-Identification/dp/B00OAFYLJC/ref=pd_bxgy_21_img_2?ie=UTF8&psc=1&refRID=JVX791WVV9Y8T9DW92KW Traxxas 2970 EZ-Peak Plus 4-Amp NiMH/LiPo Fast Charger]
| 1
| $50.00
|-
! scope="row"| 6
| '''Compass Breakout Board'''
| [https://www.dfrobot.com/product-1275.html DFRobot CMPS11 Compass]
| 1
| $29.99
|-
! scope="row"| 7
| '''Bluetooth Breakout Board'''
| [https://www.amazon.com/HC-05-Bluetooth-Pass-through-Wireless-Communication/dp/B01G9KSAF6/ref=sr_1_4?ie=UTF8&qid=1507077325&sr=8-4&keywords=arduino+bluetooth+hc-05 DSD TECH Bluetooth HC-05]
| 1
| $8.49
|-
! scope="row"| 8
| '''LIDAR Sensor'''
| [https://www.amazon.com/RPLiDAR-A1M8-Degree-Laser-Scanner/dp/B07H7X3SFF/ref=sr_1_fkmrnull_1?crid=2FSUI76G4UA8K&keywords=rplidar+a1m8+-+360+degree+laser+scanner+development+kit&qid=1552764172&s=gateway&sprefix=RPlidar%2Caps%2C263&sr=8-1-fkmrnull SEEED STUDIO RPLIDAR A1M8]
| 1
| $109.99
|-
! scope="row"| 9
| '''RPM Sensor'''
| [https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM Traxxas 6520 RPM Sensor]
| 1
| $13.70
|-
! scope="row"| 10
| '''GPS Breakout Board'''
| [https://www.adafruit.com/product/746 Adafruit Ultimate GPS Breakout v3]
| 1
| $44.30
|-
! scope="row"| 11
| '''LCD Display'''
| [https://4dsystems.com.au/ulcd-32ptu 4Dsystems 3.2 TFT-LCD ULCD-32PTU]
| 1
| $79.00
|-
! scope="row"| 12
| '''Ultrasonic Sensors'''
| [https://www.amazon.com/gp/product/B01COSN7O6/ ELEGOO HC-SR04 Ultrasonic Module]
| 5
| $12.00
|-
! scope="row"| 13
| '''GPS Antenna'''
| [https://www.amazon.com/dp/B07RRT615K/ GPS Antenna A1-UX]
| 1
| $10.98
|-
! scope="row"| 14
| '''PCB Fabrication'''
| [https://jlcpcb.com/ JLCPCB]
| 5
| $40.15
|-
! scope="row"| 15
| '''Miscellaneous'''
| [https://www.amazon.com Amazon],[https://www.mouser.com/ Mouser Electronics],[https://www.digikey.com/ Digikey],[https://anchor-electronics.com/ Anchor Electronics]
| ~
| $48.07
|-
! scope="row"|
|
|
| '''Total'''
| '''$1036.15'''
|-

|}

 

== '''Printed Circuit Board''' ==

=== Design And Architecture ===
The complete PCB (for boards and hardware peripherals) was designed using EasyEDA online software. The 4 nodes will be communicating via CAN bus and other peripherals are connected to the PCB via headers.

=== Power Section===
We have 2 power banks supplying our system. And the Servo Motor, RPM sensor and DC rear Motor (via ESC) are powered using LiPo battery (6 volts).
* Power bank #1 - Subset 2

* Power bank #2 - Subset 1, Subset 3, Bluetooth

'''NOTE:'''

'''Subset 1:'''
1. LIDAR
2. LCD
3. Compass

'''Subset 2:'''
1. Motor node
2. Driver node
3. BS node

'''Subset 3:'''
1. Geo node
2. Back ultrasonic sensor

=== Fabrication ===
* PCB was sent to fabrication to JLCPCB China which provided PCB with MOQ of 5 and 2 layers of PCB with common grounded the entire copper area.
'''DRC elements'''
* Track Width = 12
* Clearance = 10
* Via Diameter = 24
* Via Drill Diameter = 12

=== Challenges ===
* Auto-routing gave lot of challenges (only ~60% success) and sometimes the online server even crashes and faces downtime. Even local routing had lot of issues. So make sure to plan your design accordingly.
* We started our PCB design well ahead of the project. So lot of pre-planning had to be done with regard to final hardware and placement of components in order to avoid spending extra time and money while re-ordering.
* The PCB went through a lot of internal revisions even before placing order. This was time-consuming.

'''Other hardware challenges:'''
* Figuring out why various hardware peripherals (GPS, Bluetooth, LIDAR and Ultrasonic sensor) started to malfunction (devices were on but values were either inconsistent / not occurring), took a lot of time to debug. It was due to insufficient power.

 

[[File:CMPE243 S20 T2 EasyEDA.png|1040x1200px|thumb|center|PCB Layout Design in EasyEDA]]
[[File:CMPE243 S20 T2 PCB SCHEMATIC.jpg|1041x550px|thumb|center|PCB Schematic]]

<div><ul>
<li style="display: inline-block;"> [[File:CMPE243 S20 T2 PCBFRONT.jpg|thumb|none|600px|PCB Top Layer]] </li>
<li style="display: inline-block;"> [[File:CMPE243 S20 T2 PCBBACK.jpg|thumb|none|600px|PCB Bottom Layer]] </li>
</ul></div>

 

== '''CAN Communication''' ==
<Talk about your message IDs or communication strategy, such as periodic transmission, MIA management, etc.>

=== Hardware Design ===
<Show your CAN bus hardware design>

=== DBC File ===

DBC FILE: [https://gitlab.com/coder137/can-ster_truck/-/blob/dbc-improvements/projects/lpc40xx_freertos/project.dbc Gitlab]

<pre>
VERSION ""

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

BS_:

BU_: DBG DRIVER IO MOTOR SENSOR GEO

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" GEO,MOTOR,SENSOR

BO_ 101 GEO_HEARTBEAT: 1 GEO
SG_ GEO_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,MOTOR,SENSOR

BO_ 102 MOTOR_HEARTBEAT: 1 MOTOR
SG_ MOTOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,SENSOR

BO_ 103 SENSOR_HEARTBEAT: 1 SENSOR
SG_ SENSOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,MOTOR

BO_ 200 MOTOR_STEERING: 1 DRIVER
SG_ MOTOR_STEERING_direction: 0|8@1- (1,0) [-2|2] "" MOTOR

BO_ 210 DRIVER_COORDINATES: 8 DRIVER
SG_ DRIVER_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
SG_ DRIVER_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 220 MOTOR_SPEED: 1 DRIVER
SG_ MOTOR_SPEED_processed: 0|8@1- (1,0) [-3|3] "" MOTOR

BO_ 300 GEO_DEGREE: 8 GEO
SG_ GEO_DEGREE_current: 0|32@1+ (0.000001,0) [0|360] "degrees" DRIVER
SG_ GEO_DEGREE_required: 32|32@1+ (0.000001,0) [0|360] "degrees" DRIVER

BO_ 310 GEO_DESTINATION_REACHED: 1 GEO
SG_ GEO_DESTINATION_REACHED_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 400 MOTOR_SPEED_FEEDBACK: 4 MOTOR
SG_ MOTOR_SPEED_current: 0|32@1+ (0.1,0) [0|60] "kph" DRIVER

BO_ 500 SENSOR_BT_COORDINATES: 8 SENSOR
SG_ SENSOR_BT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
SG_ SENSOR_BT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 510 SENSOR_SONARS: 8 SENSOR
SG_ SENSOR_SONARS_left: 0|21@1+ (0.001,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right: 21|21@1+ (0.001,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle: 42|21@1+ (0.001,0) [0|0] "cm" DRIVER

BO_ 520 SENSOR_LIDAR: 8 SENSOR
SG_ SENSOR_LIDAR_middle: 0|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_slight_left: 16|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_slight_right: 32|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_back: 48|16@1+ (1,0) [0|0] "cm" DRIVER

BO_ 530 MOTOR_KEY: 1 SENSOR
SG_ MOTOR_KEY_val: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 900 GEO_CURRENT_COORDINATES: 8 GEO
SG_ GEO_CURRENT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" DBG
SG_ GEO_CURRENT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" DBG

BO_ 901 GEO_DISTANCE_FROM_DESTINATION: 4 GEO
SG_ GEO_distance_from_destination: 0|32@1+ (0.001,0) [0|0] "meters" DBG

BO_ 902 MOTOR_INFO_DBG: 4 MOTOR
SG_ MOTOR_INFO_DBG_rps: 0|16@1+ (1,0) [0|0] "" DBG
SG_ MOTOR_INFO_DBG_pwm: 16|16@1+ (0.001,0) [0|0] "" DBG

BO_ 903 LIPO_BATTERY_VOLTAGE_DBG: 4 MOTOR
SG_ LIPO_BATTERY_VOLTAGE_val: 0|32@1+ (0.01,0) [0|0] "volts" DBG

BO_ 904 CURRENT_CHECKPOINT_DBG: 1 GEO
SG_ CURRENT_CHECKPOINT_val: 0|8@1+ (1,0) [0|0] "" DBG

CM_ "--BU (Network Node) Information--";
CM_ BU_ DRIVER "The driver controller of the car";
CM_ BU_ GEO "The geo controller of the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";

CM_ "--BO (Message) Information--";
CM_ BO_ 100 "Driver Sync message used to synchronize the controllers";
CM_ BO_ 101 "Geo Sync message used to synchronize the controllers";
CM_ BO_ 102 "Motor Sync message used to synchronize the controllers";
CM_ BO_ 103 "Sensor Sync message used to synchronize the controllers";

CM_ BO_ 200 "Steering direction values sent by Driver Node to Motor Node";
CM_ BO_ 210 "Driver Destination coordinates sent by Driver Node";
CM_ BO_ 220 "Required motor speed computed from Driver Node to Motor Node";

CM_ BO_ 300 "Current and computer/required degree values sent by Geo Node";
CM_ BO_ 310 "Indicator signal to check if the RC car has reached the destination";

CM_ BO_ 400 "Current motor info (rps and kph) sent as feedback to the Driver Node";

CM_ BO_ 500 "Coordinate BT values (destination coordinates) sent by Sensor Node";
CM_ BO_ 510 "LIDAR - Distance from obstacle detected in each sector";
CM_ BO_ 520 "Ultrasonic Sensor - Distance from obstacle detected by each sensor";
CM_ BO_ 530 "Start/Stop signal from the Bluetooth app";

CM_ BO_ 900 "Destination coordinates for BUSMASTER debugging";
CM_ BO_ 901 "Distance from destination";
CM_ BO_ 902 "Supplied PWM value to the motor and its RPM";
CM_ BO_ 903 "LIPO Battery Voltage";
CM_ BO_ 904 "Current checkpoint of the car";

CM_ "--SG (Signal) Information for Heartbeats--";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver node";
CM_ SG_ 101 GEO_HEARTBEAT_cmd "Heartbeat command from the geological node";
CM_ SG_ 102 MOTOR_HEARTBEAT_cmd "Heartbeat command from the motor node";
CM_ SG_ 103 SENSOR_HEARTBEAT_cmd "Heartbeat command from the sensor node";

CM_ "--SG (Signal) Information for DRIVER Node--";
CM_ SG_ 200 DRIVER_STEERING_direction "Calculated Driver Steering values (-2,2) for Motor";
CM_ SG_ 210 DRIVER_COORDINATES_latitude "Destination Latitude coordinate";
CM_ SG_ 210 DRIVER_COORDINATES_longitude "Destination Longitude coordinate";
CM_ SG_ 220 MOTOR_SPEED "Calculated Driver speed values (-3,3) for Motor";

CM_ "--SG (Signal) Information for GEO Node--";
CM_ SG_ 300 GEO_DEGREE_current "Current Geo Degree relative to true north";
CM_ SG_ 300 GEO_DEGREE_required "Calculated Geo Degree computed by Haversine Formula";
CM_ SG_ 310 GEO_DESTINATION_REACHED "Indicator signal to check if the RC car has reached the destination";

CM_ "--SG (Signal) Information for MOTOR Node--";
CM_ SG_ 400 MOTOR_SPEED_FEEDBACK "Feedback speed (kph) sent by Motor Node";

CM_ "--SG (Signal) Information for SENSOR Node--";
CM_ SG_ 500 SENSOR_BT_COORDINATES_latitude "Destination Latitude received over Bluetooth";
CM_ SG_ 500 SENSOR_BT_COORDINATES_longitude "Destination Longitude received over Bluetooth";
CM_ SG_ 510 SENSOR_SONARS_left "Ultrasonic Sensor attached to the left side";
CM_ SG_ 510 SENSOR_SONARS_right "Ultrasonic Sensor attached to the right side";
CM_ SG_ 510 SENSOR_SONARS_middle "Ultrasonic Sensor attached to the middle";
CM_ SG_ 510 SENSOR_SONARS_back_left "Ultrasonic Sensor attached to the back left side";
CM_ SG_ 510 SENSOR_SONARS_back_right "Ultrasonic Sensor attached to the back right side";
CM_ SG_ 520 SENSOR_LIDAR_middle "Lidar sensing the middle sector (-15 to 15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_left "Lidar sensing the slight left sector (-45 to -15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_right "Lidar sensing the slight right sector (15 to 45 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_back "Lidar sensing the back of the car (165 to 195 degrees)";
CM_ SG_ 530 MOTOR_KEY_val "1 -> Start the motor from the app, 0 -> Stop";

CM_ SG_ 900 GEO_CURRENT_COORDINATES_latitude "Current Latitude";
CM_ SG_ 900 GEO_CURRENT_COORDINATES_longitude "Current Longitude";
CM_ SG_ 901 GEO_distance_from_destination "Distance from destination";
CM_ SG_ 902 MOTOR_INFO_DBG_rps "Current RPS value of the motor";
CM_ SG_ 902 MOTOR_INFO_DBG_pwm "Supplied motor PWM value";
CM_ SG_ 903 LIPO_BATTERY_VOLTAGE_val "LIPO Battery Voltage";
CM_ SG_ 904 CURRENT_CHECKPOINT_val "Current checkpoint of the car";

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

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

BA_ "GenMsgCycleTime" BO_ 100 1000;
BA_ "GenMsgCycleTime" BO_ 200 50;
BA_ "FieldType" SG_ 100 DRIVER_HEARTBEAT_cmd "DRIVER_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 102 GEO_HEARTBEAT_cmd "GEO_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 103 MOTOR_HEARTBEAT_cmd "MOTOR_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 104 SENSOR_HEARTBEAT_cmd "SENSOR_HEARTBEAT_cmd";

BA_ "FieldType" SG_ 200 MOTOR_STEERING "MOTOR_STEERING";
BA_ "FieldType" SG_ 230 MOTOR_SPEED_val "MOTOR_SPEED_val";
BA_ "FieldType" SG_ 310 GEO_DESTINATION_REACHED_cmd "GEO_DESTINATION_REACHED_cmd";

VAL_ 100 DRIVER_HEARTBEAT_cmd 2 "DRIVER_HEARTBEAT_cmd_REBOOT" 1 "DRIVER_HEARTBEAT_cmd_SYNC" 0 "DRIVER_HEARTBEAT_cmd_NOOP" ;
VAL_ 101 GEO_HEARTBEAT_cmd 2 "GEO_HEARTBEAT_cmd_REBOOT" 1 "GEO_HEARTBEAT_cmd_SYNC" 0 "GEO_HEARTBEAT_cmd_NOOP";
VAL_ 102 MOTOR_HEARTBEAT_cmd 20 "MOTOR_HEARTBEAT_cmd_REBOOT" 10 "MOTOR_HEARTBEAT_cmd_SYNC" 0 "MOTOR_HEARTBEAT_cmd_NOOP" ;
VAL_ 103 SENSOR_HEARTBEAT_cmd 200 "SENSOR_HEARTBEAT_cmd_REBOOT" 100 "SENSOR_HEARTBEAT_cmd_SYNC" 0 "SENSOR_HEARTBEAT_cmd_NOOP" ;

VAL_ 200 MOTOR_STEERING_direction -2 "MOTOR_STEERING_hard_left" -1 "MOTOR_STEERING_slight_left" 0 "MOTOR_STEERING_straight" 1 "MOTOR_STEERING_slight_right" 2 "MOTOR_STEERING_hard_right";
VAL_ 220 MOTOR_SPEED_processed -3 "MOTOR_SPEED_reverse_fast" -2 "MOTOR_SPEED_reverse_medium" -1 "MOTOR_SPEED_reverse_slow" 0 "MOTOR_SPEED_neutral" 1 "MOTOR_SPEED_forward_slow" 2 "MOTOR_SPEED_forward_medium" 3 "MOTOR_SPEED_forward_fast";
VAL_ 310 GEO_DESTINATION_REACHED_cmd 1 "GEO_DESTINATION_REACHED_cmd_REACHED" 0 "GEO_DESTINATION_REACHED_cmd_NOT_REACHED";
</pre>

 

== '''Motor Controller''' ==
<Picture and link to Gitlab>

This controller is used to control the components of the car-related to motor. We can control the speed and steering of the car having interfaced with various components with the SJ-2 board. The servo motor is controlled via PWM and is used to set the steering direction of the car. The DC motor is controlled by the Electronic Speed Controller (ESC) via PWM for speed. We read the speed of the car by using an RPM sensor. By using the RPM sensor values, a feedback loop has been designed to regulate the speed of the car. A state machine has been designed to manage the forward and backward movements of the car.
Additionally, a voltage divider circuit has been implemented to read the battery voltage. All motor functionality and CAN message communication is run at 10 Hz.

=== Hardware Design ===

The following diagram details the hardware implementation of the motor module with the SJTwo board:
Hardware Interface
- Servo Motor
The servo motor responds to PWM pulses. It has three pins namely Vcc, PWM Input Signal, and GND. The servo is powered using 6V from the car battery. Based on the PWM signal supplied from the SJTwo board the front wheels are turned.
- Electronic Speed Controller (ESC)
The ESC is used to control the DC motor. It is supplied power using the 7.4 V LiPo battery. It has three pins namely Vout, PWM Input Signal, and GND. Based on the PWM input signal, the speed and forward, neutral, and backward movements of the car is changed. Vout is given to the RPM sensor and Servo motor.
- DC Motor
The DC motor is controlled using the ESC. It has two pins, a positive and negative terminal. A PWM signal wire is connected to the microcontroller and the required current is provided by the LiPo battery and the ESC. The DC motor is controlled using PWM at 10Hz.

[[File:CMPE243_S20_T2_Canster_Truck_Motor_Hardware.png|thumb|center|750px| Motor Hardware System]]

Note: First calibrate the DC motor or the motor will not respond to your PWM pulses. For help with calibration go to this [https://traxxas.com/support/Programming-Your-Traxxas-Electronic-Speed-Control website]

- RPM Sensor

The RPM sensor is used to get the current speed of the car. We use the info for creating a feedback loop (PID) for maintaining the speed of the car in uphill and downhill situations. The RPM sensor mounts on the rear DC motor shaft compartment with a special assembly also provided by Traxxas. The magnet which attached to the inner gear generates a pulse each rotation. The sensor works on the hall effect principle where it provides a current across its terminal when placed in a magnet's field. The RPM sensor has three pins namely Vcc, Signal, and GND.

- Battery Voltage Divider Circuit
- (Need Niket’s help)

=== Software Design ===

The software for the motor node was divided into multiple files and made modular to improve readability and understanding of the complex logic involved. The main code modules are for:
• Servo Motor
• Electronic Speed Controller
• RPM Sensor
• Motor Wrapper
• Battery Voltage

The motor wrapper module is used to wrap all the code from the esc, servo, and rpm modules into simple to use functions to be called in the periodic tasks.
• Servo Motor
It uses the steering value sent from the driver (-2 to 2) and matches it to the appropriate PWM value for steering. This code module is run at 10Hz.
<pre>
void servo__steer_processor(int16_t steering_value) {
switch (steering_value) {
case MOTOR_STEERING_hard_left:
servo__steer_hard_left();
break;
case MOTOR_STEERING_slight_left:
servo__steer_soft_left();
break;
case MOTOR_STEERING_straight:
servo__steer_straight();
break;
case MOTOR_STEERING_slight_right:
servo__steer_soft_right();
break;
case MOTOR_STEERING_hard_right:
servo__steer_hard_right();
break;
default:
printf("\nDid not receive steering value");
}
}
</pre>
• Electronic Speed Controller

This code module is used to control the DC motor. It receives the motor direction value from the driver and sets the appropriate PWM value. Based on the value the motor is commanded to move the car forward or backwards. A switch case is implemented to set PWM values for movement in different directions along with different speeds.
<pre>
void esc__direction_processor(int16_t direction_value) {
desired_direction_value = direction_value;
switch (direction_value) {
case MOTOR_SPEED_reverse_fast:
esc__reverse_fast();
break;
case MOTOR_SPEED_reverse_medium:
esc__reverse_medium();
break;
case MOTOR_SPEED_reverse_slow:
esc__reverse_slow();
break;
case MOTOR_SPEED_neutral:
esc__neutral();
break;
case MOTOR_SPEED_forward_slow:
esc__forward_slow();
break;
case MOTOR_SPEED_forward_medium:
esc__forward_medium();
break;
case MOTOR_SPEED_forward_fast:
esc__forward_fast();
break;

default:
printf("\nDid not receive direction and speed value");
}
}
</pre>

There is also a feedback loop to control the speed. The ESC code depends on the rpm sensor code for the current speed values.
<pre>
double current_speed = get_speed_kph();
double desired_speed = desired_speed_kph;
float adjusted_duty_cycle = 0.0;
adjusted_duty_cycle = duty_cycle + (speed_to_pwm_adjustment(desired_speed, current_speed));
</pre>

[[File:CMPE243_S20_T2_Canster_Truck_Motor1.png|thumb|center|400px| Motor Flowchart 1]]

• RPM Sensor
This code module is used to get current speed data from the RPM sensor. It is based on interrupts. When the wheel rotates once, we get one pulse due to the magnet installed. This pulse generates a falling edge interrupt during which we increment the pulse counter. Since, this code is run at 1Hz we collect the number of pulses generated every one second. This gives us the number of rotations per second using which we can calculate the speed in kph.
<pre>
float rpm__calculate_speed_kph() {
uint16_t rotation_per_sec = pulse_count;
pulse_count = 0;
speed_kph = ((CIRCUMFERENCE_METER * rotation_per_sec) * (MPS_TO_KPH_CONVERSION_FACTOR)) / GEAR_RATIO;
return speed_kph;
}
</pre>

• Motor Wrapper
As mentioned above, the main function of this code module is to wrap all the other code modules and call the right functions at the appropriate frequency. The motor wrapper code also includes a state machine for ensuring a smooth transition between forward to backward state and vice versa. In order to achieve a smooth transition, a series of PWM pulses must be generated at the right time. For example, when the motor is moving from forward to backward state, a reverse value must be given first followed by at least three neutral values, and then continue with reverse values.

[[File:CMPE243_S20_T2_Canster_Truck_Motor2.png|thumb|center|400px| Motor Flowchart 2]]

=====LIPO Battery Voltage=====
The LIPO Battery Voltage was calculated using ADC in Burst Mode. A LIPO Hardware module was created for the same which contained two functions, <code>lipo__init</code> and <code>lipo__get_voltage</code>.

The voltage divider circuit is stepped down from 7.4V to 2.1V using 10K and 4K Resistor pair.

'''LIPO Initialization'''

The LIPO Initialization phase initializes the ADC, Enables Burst mode on the ADC pins and configures the Alternate Function Registers for the same.

'''LIPO Get Voltage'''

We read the raw ADC value from the LPC Hardware register. This value will be from 0 - 3.3V. However due to our voltage divider configuration the max voltage that we should theoretically get is 2.1V. This means that 2.1V corresponds to 7.4V of the LIPO Battery voltage.

The formula used is
<code>(raw_adc_value * MAX_LIPO_BATTERY_VOLTAGE_VALUE) / MAX_LIPO_ADC_VALUE</code>

=== Technical Challenges ===
<ol>
<li>Changing movements of the car from Forward to Backward and vice versa
If you just change the PWM value from say 16 (Forward) to 14(Backward), the DC motor will just stop and will not make wheels turn reverse. We discovered this problem quite late as during the initial testing we had always run the car from the start with either forward or reverse but never tried changing the direction during run-time.
Solution: The motor requires a series of PWM pulses which is specific to the car to transition from forward mode to reverse mode. In our case we had to give the PWM pulses in the following sequence. Suppose,
<ol>
<li> Forward (16) (callback_count=0)</li>
<li> Forward (16) (callback_count =1)</li>
<li> Reverse (14) (callback_count =2)</li>
<li> Neutral (15) (callback_count = 3)</li>
<li> Neutral (15) (callback_count = 4)</li>
<li> Neutral (15) (callback_count = 5)</li>
<li> Reverse (14) (callback_count = 6)</li>
<li> Continue reverse</li>
</ol>
Similarly, the reverse to forward can also be implemented.
<li>DC motor shooting off when there is an improper ground connection
When we connected the battery voltage circuit for reading the voltage from the battery, the motor would randomly shoot off every now and then.
Solution: Connect the voltage divider circuit to the common ground rather than taking the ground from the ESC.</li>
</ol>

<HR>
 

== '''Geological Controller''' ==

<Picture and link to Gitlab>

===Messages===
*GEO_HEARTBEAT: Used to check for MIA by other nodes. Highest priority message for GEO Node

*GEO_DEGREE: Sends the current degree relative to the North Pole computed by the Compass and the Required degree relative to the North Pole computed by Bearing Angle using the Current Coordinate and Destination Coordinate.

*GEO_DESTINATION_REACHED: Sets a flag, 0 for destination not reached and 1 for destination reached

*GEO_CURRENT_COORDINATES: Debug Message used to send the Current GPS Coordinates

*GEO_DISTANCE_FROM_DESTINATION: Debug message used to send the Distance from Destination

*CURRENT_CHECKPOINT_DBG: Debug message used to check which checkpoint is being navigated to

=== Hardware Design ===

[[File:CMPE243_S20_T2_GEO1.png|thumb|center|650px| Geological Diagram]]

=== Software Design ===
=====Overview=====
*Inside the `periodic_callback__initialize`
**Initialize the CAN BUS
**Initialize the GPS

*Inside the `periodic_callback__1hz`
**Handle all MIA (from other Nodes)
**Update GPS LED when init and in case of failure
**Compute the GEOLOGIC for Waypoints algorithm once every second (1000 ms)

*Inside the `periodic_callback__10hz`
**Handle CAN Incoming messages (Decode)
**Transmit CAN Geo messages (Encode and send)
**Compute the GPS Coordinate

=====Compass I2C Driver=====
An online datasheet resource was used to work with the Compass (https://www.robot-electronics.co.uk/htm/cmps11i2c.htm)
Initially the Compass I2C Driver was tested using the Terminal I2C Helper built by our Professor Preetpal Kang. Using this resource we were quickly able to read various I2C Registers and display it onto the terminal.

For our project the only required part of the Compass was the 16-bit Compass Bearing value (0-3599) i.e 0-359.9 degree values. These values were stored in the 2nd and 3rd register (Register 2 being the High Byte).
Once the raw data was received over I2C we could easily combine the data

<pre>
uint16_t bearing_value = (Reg2 << 8) | Reg3;
float rval = bearing_value / 10.0;
return rval;
</pre>
The returned value were transmitted to the Driver Node to compute its steering based on the required Bearing Angle.

=====GPS Initialization=====
GPS Initialization activates the Hardware GPIO (RX and TX), FreeRTOS Queue for UART Interrupts (UART Module) and Line Buffer Module to parse each GPS line.

=====GPS Data Parsing=====
The GPS Hardware module transmits an NMEA string over UART to the SJTwo Board. We read each character one by one and add it to the Line Buffer module.
Inside its computation loop, the Line Buffer module checks if a newline character has been received.
When a newline character has been received the entire string is extracted from the line buffer module and parsed according to its identifier ($GPRMC, $GPGGA) received and parsed into individual tokens.
For our purposes the $GPRMC NMEA string was the most appropriate and it helped us extract the Current Latitude Longitude as well as the Valid/Invalid tag for the Canster Truck.

=====GPS LED Indication for debugging=====

A simple module that checks for the GPRMC GPS Message and extracts the A or V valid (Tag). If $GPRMC NMEA string is valid, LED is set, else LED is reset. This gives us onsite debugging capabilities to know if GPS has locked onto a satellite signal.

=====GEO Logic Module Computation=====
The GEO Logic Module computes the Bearing Angle, Haversine Distance as well as the Waypoints algorithm.

'''Bearing Angle:'''

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

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

Since atan2 returns values in the range -π ... +π (that is, -180° ... +180°), to normalize the result to a compass bearing (in the range 0° ... 360°, with −ve values transformed into the range 180° ... 360°), convert to degrees and then use (θ+360) % 360, where % is (floating point) modulo.
For final bearing, simply take the initial bearing from the endpoint to the start point and reverse it (using θ = (θ+180) % 360).

The above article reference gives us the required bearing angle that our car must align itself to, to reach a particular destination coordinate from its current coordinate.
The Steering of the Canster Truck depends on the above-computed angle values.

'''Haversine Distance Formula:'''

This uses the ‘haversine’ formula to calculate the great-circle distance between two points – that is, the shortest distance over the earth’s surface – giving an ‘as-the-crow-flies’ distance between the points (ignoring any hills they fly over, of course!).

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);
note that angles need to be in radians to pass to trig functions!

The above formula is used to calculate the distance between the source coordinate (received via GPS) and the destination coordinate.
Later this was used to compute the distance between source coordinate and each individual checkpoint to traverse the shortest distance.

'''Waypoints Algorithm:'''

The Waypoints algorithm that was chosen was a slightly modified version of Djikstra’s Algorithm.
3 values were calculated before the final computation
- Distance between source and final destination (DISTsd)
- Distance between source and each individual checkpoint (DISTsc)
- Distance between each individual checkpoint and the final destination. (DISTcd)
If DISTsd was lesser than DISTcd, this checkpoint was discarded (we continue in the loop). Since we would be moving in the opposite direction, rather than towards the final destination.
If DISTsd was greater than DISTcd, then we checked the nearest checkpoint to the source.
The minimum value was set initial that was equal to DISTsd.
If DISTsc was lesser than the minimum value stored, DISTsc would become the new minimum value, and the checkpoint index and coordinates would be appropriately stored and returned from the function.
In this way we would navigate to the nearest checkpoint from the source, while also making sure NOT to travel in the opposite direction.
This logic is recomputed only when we reach the checkpoint selected and the algorithm runs again to find the next checkpoint that we need to navigate to.

=====CAN Decode Destination Coordinates=====
Destination Coordinates are received from the Bridge and Sensor Node and transmitted over the CAN Bus. The value is decoded and stored in the GEO Logic Module.
This is a very important value since our entire GEO Logic calculations are based on the Destination Coordinate.

=====CAN Encode and Send=====

The main messages that were transmitter are
#Geo Degree
#Geo Destination Reached
#Distance from Destination Debug and Checkpoint Index debug

'''Geo Degree Computation as per Waypoints Algorithm:'''

Geo Degree was computed as per the current coordinates and the most recently computed checkpoint coordinates. This bearing angle calculation w.r.t computed checkpoint would continue till we do not reach that particular checkpoint.
Once we reach the computed checkpoint, Waypoint algorithm is recomputed as per the process mentioned above and the algorithm runs again.

'''Geo Destination Reached:'''

An Area of around 4 meters was set around the destination coordinate to check if the destination had been reached.
This measurement was taken into consideration to allow for the loss in precision when transmitting data over CAN as well as any irregularities that might occur when getting values from the GPS.
Having an area of 4 meters was very accurate for all of our test runs.

'''Geo Distance from Destination Debug and Checkpoint Index Debug:'''

Getting debug information was very critical to speed up our development process. In this case we could actively see if our algorithm worked properly.
The Geo Distance from Destination was used to see if we were moving closer to our destination or veering further away from it.
The Checkpoint Index was used to see which checkpoint index we were traveling to. By knowing the placements of the Individual checkpoints we could manually as well as programmatically (via Android application) verify the working of our Canster Truck.

=== Technical Challenges ===
#DBC Challenge for GEO Coordinates -> Could not encode more than 5-6 decimal places at a time, on later investigation we found that the 10000 is an int value, however 100000 overflows the int value.
#Creating an efficient algorithm for Waypoints, O(n) complexity.
#Getting appropriate fixes for GPS when not in a completely open space.
#GPS used to fluctuate or stop giving values when Battery voltage went below a particular threshold. Always supply 3.3V constantly at a good amperage.

<HR>
 

== '''Sensor [Bridge and Sensor Controller]''' ==
<Picture and link to Gitlab>

==='''Ultrasonic Sensor'''===
====Hardware Design====
This sensor uses an ultrasonic beam to measure the distances. Based on the time taken between when the beam is sent and received back to the sensor, the distance is calculated in the node.
Apart from 5v and GND, this sensor has 2 pins ECHO and TRIG which are interfaced with the SJ-Two board via GPIO.

[[File:CMPE243_S20_T2_CansterTruck_ultrasonic_sensor.jpg|thumb|center|300px| Ultrasonic Sensor Diagram]]

====Software Design====
* Init the GPIO pin connected to TRIG of the sensor as output and for ECHO as an input port.
* Attach the interrupt on the ECHO input port.
* Store the system_clock_count before setting the trigger pulse and then set the pulse. Also keep monitoring the input port.
* Take the system_clock_count at the instant of receiving the interrupt.
Distance = (system_clock_count_at_trig - system_clock_count_after_at_echo) / 57.14

==='''Lidar Sensor'''===
====Hardware Design====
The RPLidar sensor can be powered from a 5-volt source and uses UART communication to receive commands and transmit data. It has seven pins to interface with. Two sets of the pins (four total) are for power and ground. The remaining three are for UART receive and transmit, and for making the lidar’s motor spin.

[[File:CMPE243_S20_T2_Canster_Truck_RPLidar_A1.JPG|thumb|center|300px| RPLidar A1]]

====Software Design====
In terms of the lidar, the SJ2 initializes GPIO, UART, and memory for storing the measurement values. After initialization, the command to begin scanning is sent. Here, we wait for the lidar to send a response packet, letting the host (SJ2 board) know it received the command. The response packet the lidar sends will be 7 bytes. If the correct 7 bytes are not received, the command will be sent again.

[[File:CMPE243_S20_T2_Canster Truck_Lidar_flow.jpeg|thumb|center|200px| Lidar Flow]]

Following the response packet, the lidar begins sending 5-byte measurement data. Each sample contains a distance measurement (in millimeters) and the angle (with respect to the lidar) in which it was taken. The data packet structure is shown in the following figure. In addition to containing the distance and angle, the packet includes a quality value, to indicate the reliability of the measurement, and three check bits (S, ~S, and C). As the data is received via UART, we wait until we have 5 bytes before continuing to process. Before processing the 5 bytes after receiving them, the check bits are confirmed to be correct. If they are incorrect, it will not be processed and we will wait for another sample to be received.

[[File:CMPE243_S20_T2_Canster Truck_DataPacketStructure.JPG|thumb|center|200px| Data Packet Structure]]

In the case the sample is correct, each measurement value that is in a direction of interest will be placed in an array designated to one of four directions (left, right, front, rear). Each of these directions have their own sector in the lidar’s 360-degree view.
*Right sector: 11°-30°
*Rear sector: 170°-190°
*Left sector: 330°-349°
*Front sector: 350°-370° (or 10°)

The arrays mentioned will hold roughly 20 measurements, which are every degree in the sector. In the event, objects are too far to measure, the lidar will report 0 mm. distance. Since there is no measurable obstacle, a “large” distance value of 3000 mm. is placed in the array. The smallest distance value will be taken from each array and reported to the driver node for obstacle avoidance.

=== Technical Challenges ===
====Ultrasonic====
====Lidar====
*'''Datasheet not 100% clear:''' The correct datasheet for the was a bit difficult to obtain, and the manufacturer needed to be contacted. The first document found online was high level and general information about the sensor, but the manufacturer did provide another document that contained the information of the commands and responses to and from the lidar, and their packet structure. The documents did not clearly state the angles with respect to the lidar are fixed, which left me wondering if the lidar will think the direction it is facing when powered on will become the new “zeroth” angle.

*'''UART Buffer Overflow:''' When first interfacing with the sensor, the incoming bytes of the lidar were printed on to the terminal to make sure there was a response and to make sense of the information. Since the command we sent results in 5 bytes of data per measurement samples from the lidar and the lidar measured 2000 times per second, there are will be roughly 10k Bytes per second of data incoming that need to be handled continuously. With an improperly sized UART buffer and print statements it is guaranteed to occur, making the lidar data look like random values.

*'''Proper Parsing of Measurement Data:''' After sending a command to the lidar, the sensor will send a response packet, followed by the measurement data. The initial response from the lidar is a 7-byte packet, followed by continuous 5-byte measurement samples. I needed to make sure however I handled the response would be independent of how the measurement is handled, so as not to create a potential unwanted offset when receiving measurements.

*'''Object Detection with Received Data:''' Once proper communication was set up with the lidar and measurement data was getting decoded, there needed to be a way to measure when obstacles were present. If ~360 measurements are handled entirely independently from one another, it could become a complex and confusing code. To achieve a simple approach, four sectors about 20 degrees in size were used to represent the front, left, right, and rear directions.

*'''Bugs in Code:''' When first implementing the code, there were a few bugs from typos, incorrect numbers, and some faulty logic that were found with the use of unit testing. Unit testing helped find these issues and verified the logic was correct, and I would say gave me 90% confidence in my lidar handling.

<HR>
 

== '''Bridge [Bridge and Sensor Controller]'''==
<Picture and link to Gitlab>

Bridge functionality of the Bridge and Sensor Controller is to establish wireless communication between the SJ-2 Board and the android mobile device using the HC-05 Bluetooth module. The Bridge controller will be receiving start command with destination GEO coordinates and stop command. The Bridge controller will be transmitting the required sensor data and debug information to be displayed on the android application.

[[File:CMPE243_S20_T2_BRIDGE.png|thumb|center|500px| Bridge Diagram]]

===Bluetooth===

==== Software Design ====
<ol>
<li> Low-Level Layer
In this layer, similar to the GPS the UART GPIO was initialized (RX, TX), FreeRTOS Queue was initialized for UART Interrupts and the line buffer module was initialized to parse strings.

Two basic functions '''bt__read''' and '''bt__write''' were implemented.
As the name suggested, '''bt__write''' took a string as its input parameter and transmitted that data to the Android application. '''bt__read''' stored the incoming characters into the line buffer, parsed the line received into its identifier and tokens, and invoked a callback function.

Since this was a low-level layer the User would not be directly invoking this library. Instead a '''Bluetooth Wrapper''' module was created which would be invoked and used by the user.
</li>

<li>Application Layer

The Bluetooth Wrapper module had the appropriate '''read_once''' and '''write_once''' functions.

The `read_once` function internally just called the '''bt__read''' function. All of the decodings was done inside the Callback Function.
To get the Destination coordinate the string received from the Android Application was in the form of
<pre>$loc,<destination_latitude>,<destination_longitude>.</pre>
Upon receiving this data we parsed the destination_latitude and destination_longitude, which could later be accessed using getters.
We also set a start flag to notify the Driver Node that destination has been received and we can start steering towards our checkpoints.
Another command implemented was the stop command.
<pre>$stop</pre>
This was used to send a stop flag to the Driver node.

The '''write_once''' function used the getter methods from each CAN Decode message and update its internal state variables. A CSV String was created using the <pre>$canster</pre> identifier and various debugging points were appended to this message using a comma.
On the Android application side this CSV string was tokenized and displayed onto the Application Debug screen appropriately.
</li>
</ol>

==== Technical Challenges ====

<List of problems and their detailed resolutions>

<HR>
 

== '''Driver [Driver and LCD Controller]''' ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===

[[File:CMPE243_S20_T2_Canster Truck_Driver_Flowchart.png|thumb|center|750px|Driver Flowchart]]

The above block diagram explains the process flow of obstacle detection for the car. The LIDAR detects
the obstacle and depending on the distance of obstacle the car takes a slight right and slight left or a
hard right and hard left. The state of the car also depends on the value of the LIDAR and ultrasonic sensor.
The loose ends of the LIDAR for the reverse condition are checked by the ultrasonic sensors. The
The ultrasonic sensor works on the principle of trigger and echo and can detect the obstacles very close by.
The range of the Ultrasonic sensor is lower than the LIDAR. Finally, if no obstacle is detected the car goes
straight until the destination is reached. The speed of the car is also various when an obstacle is detected to
avoid the crash and the car’s smooth transition from one state to another. The key to the android
application controls the start and stop the process of the car. If the key is not pressed, then the stays in the

neutral state. The speed of the car is controlled by the changing duty cycle of the input voltage. There
are seven-speed levels in which the motor can run on. These speed levels are Forward Slow, Medium,
Fast, Reverse Slow, Medium, Fast, and Neutral. The Neutral is the stop condition with a 0% duty cycle.

=== Technical Challenges ===

< List of problems and their detailed resolutions>

<HR>
 

== '''LCD [Driver and LCD Controller]''' ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
The GLCD used was created by 4DSystems, using their IDE a UI was created. Each UI component could be controlled by sending UART data targeted at the widget address.
The best part about this GLCD was that we had a lot of interactive widgets to display debugging information in real-time.
The GLCD code was divided into 3 parts:
<ol>
<li>'''Low-Level Initialization'''
Initialize the low-level hardware interfaces to send and receive data from the GLCD.
Similar to the GPS and Bluetooth, The UART GPIO was initialized (RX, TX), FreeRTOS Queue was initialized for UART Interrupt and line buffer was used to get a stream of data for parsing.

Low-level '''read''' and '''write''' commands were used as per the working of the GLCD Module.
When Reading data pertaining to a widget on the GLCD we would need to send a particular response packet.
<pre>
void lcd__read(lcd_object_e object_id, uint8_t object_index, uint8_t *response, uint16_t *response_data) {

uint8_t checksum = READ_OBJ ^ object_id ^ object_index;
uint8_t buffer[] = {READ_OBJ, object_id, object_index, checksum};

lcd__write_data(buffer, sizeof(buffer) / sizeof(uint8_t));
lcd__read_response_id(response);
lcd__read_response_data(response_data);
}
</pre>

The response_data returned contains the Widget ID as well as the current value stored on that widget.

When Writing data pertaining to a widget on a GLCD the process is similar to the above mentioned code.
<pre>
void lcd__write(lcd_object_e object_id, uint8_t object_index, uint8_t msb, uint8_t lsb, uint8_t *response) {
uint8_t checksum = WRITE_OBJ ^ object_id ^ object_index ^ msb ^ lsb;
uint8_t buffer[] = {WRITE_OBJ, object_id, object_index, msb, lsb, checksum};

lcd__write_data(buffer, sizeof(buffer) / sizeof(uint8_t));
lcd__read_response_id(response);
}
</pre>

However in this case we receive only an ACK or NACK from the system. ACK would mean that the write to GLCD widget was successful and the widget now stored appropriate values. NACK would mean that a particular error has occurred. The errors could be regarding baud rate, incorrect bit format, incorrect index values, etc.
</li>
<li>'''GLCD Wrapper for Widgets'''
The above low-level code had generic read and write functions. However for our UI we were only using 3 Widgets. All of which had '''different Indexes''' and '''Widget IDs'''.
Therefore a very simple library was created to easily interface with those widgets
<pre>
bool lcd_wrapper__read_led(uint8_t index);
uint16_t lcd_wrapper__read_meter(uint8_t index);
uint16_t lcd_wrapper__read_leddigit(uint8_t index);

bool lcd_wrapper__write_led(uint8_t index, bool value);
bool lcd_wrapper__write_meter(uint8_t index, uint16_t value);
bool lcd_wrapper__write_leddigit(uint8_t index, uint16_t value);
</pre>

The above code is self-explanatory read and write functions for '''LED''', '''METER''', and '''LED DIGIT'''.
</li>
<li>'''GLCD UI'''
Now that we had our low level and Widget wrapper working properly, we wanted to create our Dynamic UI as well. The code would need to be robust enough to handle any UI that we create on the GLCD which could be reflected equivalently in our C Code.

<pre>
static void lcd_ui__update_ui(void) {

lcd_wrapper__write_led(LCD_LED_DRIVER_MIA_INDEX, driver_mia_led);
lcd_wrapper__write_led(LCD_LED_SENSOR_MIA_INDEX, sensor_mia_led);
lcd_wrapper__write_led(LCD_LED_GEO_MIA_INDEX, geo_mia_led);
lcd_wrapper__write_led(LCD_LED_MOTOR_MIA_INDEX, motor_mia_led);

// kph is always in the range of 0 - 10
lcd_wrapper__write_meter(LCD_METER_KPH_INDEX, kph_meter % 11);

// These will be in the Range of 0-99
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_RPM_INDEX, rpm_leddigit % 100);
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_CURRENTDEGREE_INDEX, cdegree_leddigit % 100);
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_REQUIREDDEGREE_INDEX, rdegree_leddigit % 100);
}
</pre>

As we can see the `lcd_ui__update_ui` function was called periodically inside the 1Hz function. It updated the screen in real time based on the static values that were stored AND updated inside the LCD UI module.
The Constant INDEX values stored were directly mapped onto the Index values were received from the 4DWorkshop UI Software.
</li>
</ol>

=== Technical Challenges ===

< List of problems and their detailed resolutions>

<HR>
 

== '''Android Application''' ==
[https://gitlab.com/akhilcherukuri/can-ster_truck_application Gitlab]
=== Software Design ===

<div><ul>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android1.jpg|thumb|none|250px|Splash Screen]]</li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android2.jpg|thumb|none|250px|Main Activity Screen]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android3.jpg|thumb|none|250px|Map Activity Screen]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android4.jpg|thumb|none|250px|Info Activity Screen 1]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android5.jpg|thumb|none|250px|Info Activity Screen 1]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android6.jpg |thumb|none|250px|Debug Activity Screen]]</li>
</ul></div>

The application consists of a total of 5 Activities:

*'''Main Activity:'''
**This is the app launch display screen
**It will check for all the required permission onStart().
**Has search button for connecting from a paired device list view
**Once device is clicked, an intent will start the Map Activity
*'''Map Activity:'''
** For this requirement we are using the Google Maps Fragment, for the map fragment to function we must request an API key from Google and set the key in the manifest of the application.
** Destination marker(Red Marker) is set using setOnMapClickListener to which the car will navigate to, the destination can be changed by clicking elsewhere on the Map Fragment. The marker can be removed using setOnMarkerClickListener.
** When the start button is pressed, the start command identifier along with destination latitude and longitude is sent to the car via the write thread. A background thread is started along with it to indicate the current car's position(Green Marker) along with a plotline between the current position and destination.
** When the stop button is pressed, the stop command identifier is sent to the car, to stop and turn off the car.
*'''Info Activity:'''
** Messages from Geological, Driver, Motor coming from CAN bus are decoded by the Sensor and Bridge controller and sent to the Android application as a string.
** The received string is parsed and categorizes the data to store it in the required textView to be displayed.
** Bluetooth status, Lidar Values, Ultrasonic Sensor Values, Motor Speed, Motor RPM, Motor PWM, Cars' current location, Compass Heading, Distance till Destination, Checkpoint Index is displayed. This was useful for debugging purposes and allowed us to avoid scanning the mounted LCD or CAN Busmaster on PC during drives.
*'''Debug Activity:'''
**The main function of this activity is to check all RAW RX and RAW TX messages and create a log of all the data received and sent.
*'''Bluetooth Connection Service Activity''' :
**This is the background activity that handles all the threads required for transmission and receiving data using Bluetooth connections. It has 3 running threads which is called inside other activities using a handler:
** Accept Thread - Listens to BluetoothServerSocket using listenUsingRfcommWithServiceRecord. In order for the RF communication socket to connect to the HC-05, we used the following UUID: 00001101-0000-1000-8000-00805F9B34FB. This is a generic SSP Bluetooth UUID that enables the socket to directly connected to HC-05 and maintain the connection.
** Connect Thread - Creates a Bluetooth socket using createRfcommSocketToServiceRecord
** Connected Thread - Creates socket.getInputStream(); and socket.getOutputStream(); when bytes are available in input stream it will read them into a buffer.
***All messages for activities are done by Handler mHandler.obtainMessage(); mHandler.sendMessage();

*'''Receieved string''':
** A String is sent to the Bluetooth app from HC-05 and when it receives a string with identifier "$canster", the message is prased accordingly by using the string delimiter ',' and is ended by the newline character '\n' which will remove the data from StringBuffer.
** Example: $canster,37.339334,-121.881123,37.338713,-121.880685,10.123,20.133,30.123,10.5,88.1,99.2,-2,1,44,7,11,22,33,-3,23\n

[[File:CMPE243_S20_T2_BLUETOOTHFLOWCHART.png|thumb|center|650px| Android Application Flowchart]]

=== Technical Challenges ===

<HR>
 

== '''Mangaement''' ==
===Team Management ===
===Git Management===

Git Management amongst 6 team members was definitely a very challenging task. Depending on our initial design we could’ve had a lot of merge conflicts. However those risks were mitigated by spending a LOT of time in the initial stages to decide our pipeline and structure.

<li>There are certain components in our system that were COMMON. For example the CAN initialization, communication and decodes were all similar for the most part between all the 4 Controllers. The utility modules used were also similar in nature</li>
<li>Thus we made a common branch that contained the templates for CAN Nodes (not Controllers), Hardware code and Utility functions.
<ol>
<li>Later this common branch was forked into an individual Controller specific branch (SENSOR, GEO, MOTOR or DRIVER).</li>
<li>Only the Logic folder contained Controller specific code, specific to that controller.</li>
</ol>
<li>This gave us a lot of flexibility since all the team members had similar APIs to work with on all 4 branches. This promoted easy understanding and learning.
<ol>
<li>Many team members frequently worked on 2 or more controllers at a time where can messages were concerned. Having a APIs also meant that just the can_handler needed to be updated regularly followed by the equivalent logic code. </li>
<li>Inside the logic folder, getters to the can node modules were frequently used.</li></ol>
<pre>
├───can_module
│ ├───can_bus_initializer
│ ├───can_constants
│ ├───can_driver_node
│ ├───can_geo_node
│ ├───can_handler
│ ├───can_motor_node
│ ├───can_sensor_node
│ └───test
├───hardware
│ ├───bt
│ ├───compass
│ ├───gps
│ ├───lcd
│ ├───test
│ └───ultrasonic
├───logic
│ ├───driver_obstacle
│ ├───driver_state
│ ├───geo_logic
│ └───test
├───periodics
│ └───test
└───utility
├───line_buffer
└───test
</pre>

'''Challenges'''
<li>It was initially a bit of a learning curve to understand the flow of the repository</li>
<li>When using a git management system with different versions in each branch it became very tough when the number of branches suddenly exploded in size. A lot of relevant code was stuck in a lot of different branches.
<ol>
<li>This happened mainly due to assignment submissions and unclosed MRs that eventually became stale.</li>
<li>Our strategy was to abandon these MRs and keep forking from these branches without merging it back into its final controller branch.</li>
<li>The latest branches that were kept were aptly named `<controller>_bleeding_edge_dev` branches since they were never merged back from where they were forked.</li>
</ol>
<li>Since a lot of our code also depended on the DBC autogenerated code, we could not suddenly change the DBC Message names once they were established since it caused a change in the Struct name that was generated and used.
<ol>
<li>Our solution to this was to keep everything backward compatible. We added new function names without deleting old DBC messages.</li>
<li>In certain places where we wanted to modify a function name it was done one by one so that a lot of the code is not broken at one time.</li>
</ol>
<li>Common Branches eventually became stale as our progress continued on the bleeding edge branches
<ol>
<li>For example certain GPS features needed to be added which were done on the GEO_bleeding_edge_dev branch but never pushed or cherry-picked back into the COMMON branch.</li>
<li>This was a similar issue to our 2nd point but manageable since the goal of the COMMON branch was to provide a template for further work and nothing more.</li>
<li>At the end of the day each controller is its own Individual Project and while the messages between them are same. The Hardware code does not need to be same.</li>
<li>This also prompted team-members to ask if we could delete unused hardware or logic file code (which wasn’t being used and was imported from the template). This was also fine and can be done during cleanup stage. However we eventually got used to the Modular system of our project so much so that we did not worry about the additional modules that were present in each branched controller project.</li>
</ol>

<HR>
 

== '''Conclusion''' ==
CMPE243 gives one of the best experiences one could ever get in their academic life. The course is designed to give an insight into how the industry functions and enhances both technical and management skills. Apart from learning how to work and implement application of CAN protocol, one can get a hands-on experience with version control, unit-testing and software design. Overall it was a very great journey.

=== Project Video ===

=== Project Source Code ===

=== Advise for Future Students ===
'''GENERAL:'''
* Form your team and start the project as early as you can.
* Clearly discuss what role each individual should do and ensure that progress is regularly tracked so that the team doesn't fall back on any schedule.
* Since lot of code and hardware integration is involved with this project, make sure testing is thoroughly and periodically done and make note of all the issues found.
'''HARDWARE:'''
* Decide on how you would power up the peripherals. We had issues with Bluetooth (not connecting), GPS (lock not happening) and LIDAR (giving incorrect values). After lot of cycles of hardware and software debugging, we found that the issue was with power. Choose wisely as to which peripherals must be connected to which power bank.
* PCB design is time consuming as there is a lot of hardware components involved and a huge responsibility falls on the designer to know the about each component. Coordinating with multiple team members and verifying with them if their respective hardware is correct takes a lot of time. So start well ahead.
* Make sure to expose some extra GPIO and GND pins for future use.
'''MOTOR:'''
*You can use the LiPo battery to power the RPM and servo motor instead of using a separate power source. Use Vout from the ESC to get 6V.
*Start the PID control calibration early on as you will need to do extensive testing to get it working.

=== Acknowledgement ===
<HR>
Firstly we would like to express our gratitude to Professor Preetpal Kang for his guidance throughout the semester and providing us with this opportunity. We would also like to thank the ISA members Vignesh Kumar Venkateshwar and Aakash Vrajlal Chitroda for being available whenever in need and guiding us to complete the project.

== '''References''' ==

===Motor Controller===
===Geological Controller===
* Movable Scripts: [https://www.movable-type.co.uk/scripts/latlong.html Calculate distance, bearing and more between Latitude/Longitude points]
* CMPS11:[https://www.robot-electronics.co.uk/htm/cmps11i2c.htm I2C Configuration]

===Bridge and Sensor Controller===
===Driver and LCD Controller===
*LCD Software: [https://4dsystems.com.au/ulcd-32ptu 4Dsystems]
===Android===
*Youtube Channel: [https://www.youtube.com/channel/UCoNZZLhPuuRteu02rh7bzsw Coding with Mitch]
*Android Developers: [https://developer.android.com/guide/topics/connectivity/bluetooth Website][https://github.com/googlearchive/android-BluetoothChat Github]
*Udemy Course: [https://www.udemy.com/course/the-complete-android-oreo-developer-course/ Complete Android Oreo Developer Course]
===PCB Design===
*EDC Tool: [https://easyeda.com/ EasyEDA]

S20: Canster Truck

2020-05-22T05:32:56Z

Proj user22: /* Motor Controller */

[[File:CMPE243_S20_T2_Canster_Truck_Logo.png|thumb|455px|caption|right|CAN-STER TRUCK LOGO]]

== '''Abstract''' ==
'''The Canster Truck Project is an autonomous RC car with CAN Bus interfaced controllers. The development of the RC car's subsystem modules (Interfacing of Ultrasonic Sensor, LIDAR, Bluetooth, GPS, Compass and CAN modules) was divided among six team members. The aim of the project is to develop an autonomous RC Car which can navigate from one source location to the selected destination on the app by avoiding obstacles in its path using sensors. Waypoints algorithm is used as the path finding technique.'''

 

== '''Introduction and Objectives''' ==

'''The project was divided into 7 modules:'''

* '''Bridge and Sensor Controller'''
* '''Motor Controller'''
* '''Geological Controller'''
* '''Driver and LCD Controller'''
* '''Hardware Integration'''
* '''Android Application'''
* '''Testing & Code Review'''

'''RC Car Objectives'''
'''1. Driver and LCD Controller''' - Handles algorithms for obstacle avoidance, route maneuvering, and waypoints
'''2. Geological Controller''' - Recieves coordinates from GPS and Heading from Compass for navigation
'''3. Motor Controller''' - Controls movements of the RC Car
'''4. Bridge and Sensor Controller''' - Detects surrounding objects and interfaces android application to controller via bluetooth
'''Team Objectives'''

[[File:CMPE243_S20_T2_High_Level_System_Diagram.png|thumb|center|800px| High Level System Diagram]]

 

== '''Team Members and Responsibilities''' ==

'''Gitlab Project Link''' - [https://gitlab.com/coder137/can-ster_truck '''Canster Truck''']
 

*'''Niket Naidu''' [https://www.linkedin.com/in/niket-naidu-30090a134/ LinkedIn] [https://gitlab.com/coder137 Gitlab]
** '''Geological Controller''' : Waypoint Algorithm, Haversine and Bearing Angle logic
** '''Driver and LCD Controller''' : GLCD
** '''Bridge and Sensor Controller''' : Bluetooth
** '''Testing & Code Review'''

*'''Ganesh Ram Pamadi''' [https://www.linkedin.com/in/ganeshram93/ LinkedIn] [https://gitlab.com/ganeshram2493 Gitlab]
** '''Hardware Integration'''
** '''Testing & Code Review'''
** '''Driver Controller'''
** '''Motor Controller'''

*'''Nikhil Pabbisetty''' [https://www.linkedin.com/in/nikhilpabbisetty/ LinkedIn] [https://gitlab.com/nikhilpeoria Gitlab]
** '''Bridge and Sensor Controller'''
** '''Motor Controller'''

*'''Akhil Cherukuri''' [https://www.linkedin.com/in/akhilcherukuri/ LinkedIn] [https://gitlab.com/akhilcherukuri Gitlab] [https://github.com/akhilcherukuri Github]
** '''Android Application'''
** '''Bridge and Sensor Controller'''

*'''Ashish Anant Ladage''' [https://www.linkedin.com/in/ashish-anant-ladage-7bb3a214b/ LinkedIn] [https://gitlab.com/ashishladage1 Gitlab]
** '''Driver and LCD Controller'''
** '''Hardware Integration'''
** '''Motor Controller'''

*'''Jesus De Haro De Reza''' [https://www.linkedin.com/in/jesus-de-haro-66342424/ LinkedIn] [https://gitlab.com/deharo27 Gitlab]
** '''Bridge and Sensor Controller'''
** '''Motor Controller'''

 

== '''Administrative Responsibilities''' ==
* '''Team Lead''' - [https://www.linkedin.com/in/niket-naidu-30090a134/ '''Niket Naidu''']
* '''Git Repository Manager''' - [https://www.linkedin.com/in/niket-naidu-30090a134/ '''Niket Naidu''']
* '''Bill Of Materials Manager''' - [https://www.linkedin.com/in/akhilcherukuri '''Akhil Cherukuri''']
* '''Wiki Report Manager''' - [https://www.linkedin.com/in/akhilcherukuri '''Akhil Cherukuri''']

 

== '''Schedule''' ==

{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-

! scope="row"| '''1'''
| style="text-align:center;" |'''02/11/2020'''
| style="text-align:center;" |'''02/17/2020'''
|
*'''Form teams and decide group name'''
*'''Review past projects'''
*'''Slack: Create project group and invite Preet'''
*'''GitLab: Create project groups repository'''
*'''Analysis of component required'''

|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''2'''
| style="text-align:center;" |'''02/18/2020'''
| style="text-align:center;" |'''02/24/2020'''
|
*'''Study CAN Communication'''
*'''Create Bill of Materials'''
*'''Order RC Car'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''3'''
| style="text-align:center;" |'''02/25/2020'''
| style="text-align:center;" |'''03/02/2020'''
|
*'''Setup team finance management using Splitwise application'''
*'''Complete Bill of Materials'''
*'''Order all other required components'''
*'''Wikipedia: Setup project report template'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''4'''
| style="text-align:center;" |'''03/03/2020'''
| style="text-align:center;" |'''03/09/2020'''
|
*'''Read the respective datasheets and manuals for each component'''
*'''Test each component for working conditions'''
|
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''5'''
| style="text-align:center;" |'''03/10/2020'''
| style="text-align:center;" |'''03/16/2020'''
|
*'''Assign team responsibilities and roles'''
*'''Setup team project management environment (ClickUp)'''
*'''Define CAN DBC'''
*'''Research GPS antennas and order'''
*'''Android: Environmental setup of Android Studio and enable version control'''
*'''Hardware : Decide PCB editing software (easyEDA)'''
*'''Hardware : Draft schematic for required PCB design'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''6'''
| style="text-align:center;" |'''03/17/2020'''
| style="text-align:center;" |'''03/23/2020'''
|
*'''Hardware : Create model of PCB''' 
*'''Android: Add a Button for changing bluetooth connection status in the application''' 
*'''Geological: Interface Compass module with SJ-2 board using I2C interface''' 
*'''Geological: Interface GPS module with SJ-2 board using the UART interface''' 
*'''Geological: Parse raw data to get meaningful values for GPS and Compass''' 
*'''Sensor: Interface and check the functionality of ultrasonic sensors to the SJ-2 board''' 
*'''Motor: Interface of Servo & DC motor to the SJ-2 board and check for basic functionality''' 
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''7'''
| style="text-align:center;" |'''03/24/2020'''
| style="text-align:center;" |'''03/30/2020'''
|
*'''Hardware : Finalize components placement on PCB.''' 
*'''Motor: Add PWM functionality and test the code on DC and servo motors''' 
*'''Sensor: Interface and check and study the output readings of Lidar sensor with SJ-2 board over UART''' 
*'''LCD Display: Explore UI designing of LCD''' 
*'''Hardware: Finalize on optimal ultrasonic sensor placements''' 
*'''Android: Initiate Bluetooth communication and show staus via text view''' 
*'''Wikipedia: Establish final wiki schedule'''
*'''Complete CAN communication format for each controller and link DBC file to the Wiki'''
*'''Complete high-level system block diagram'''
*'''Complete unit-level block diagrams'''
*'''Bridge: Interface HC-5 bluetooth module with Sj-2 board using serial communicaton'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''8'''
| style="text-align:center;" |'''03/31/2020'''
| style="text-align:center;" |'''04/06/2020'''
|
*'''Hardware: Analyze PCB model and order PCB Circuit board''' 
*'''Android: Initiate Bluetooth communication and send "Hello World".''' 
*'''Wikipedia: Start adding information/images/diagrams to the relevant sections'''
*'''Motor: Configure ESC for correct speed outcome according to frequency & PWM values''' 
*'''Motor: Finish RPM sensor hardware and software implementation and integration''' 
*'''Sensor: Read output from Lidar and setup structure for outputting for DBC''' 
*'''Geological: Implement waypoints algorithm''' 
*'''Driver: Implement obstacle avoidance algorithm''' 
*'''Bridge: Pass data such as "Hello World" from HC-05 bluetooth module to bluetooth terminal android application'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''9'''
| style="text-align:center;" |'''04/07/2020'''
| style="text-align:center;" |'''04/13/2020'''
|
*'''Hardware: Remove Unused parts from RC Car''' 
*'''Hardware: Mount PCB and 3D Parts''' 
*'''Motor: Decide different cut-off values from sensor to command right /slight right/ straight/ slight left/ left to motor.''' 
*'''Android: Embed Google Maps API for setting the car's destination.''' 
*'''LCD: Work to show RC cars live status information(battery level, current speed, long, lat, bearing, sensor data, etc)''' 
*'''Driver: Test obstacle avoidance algorithm and fine-tune sensor readings''' 
*'''Geological: Test checkpoint algorithm''' 
*'''Bridge: Establish two way communication between android application and bluetooth module''' 
*'''Update Bill of Materials for miscellaneous hardware'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''10'''
| style="text-align:center;" |'''04/14/2020'''
| style="text-align:center;" |'''04/20/2020'''
|
*'''Hardware: Integrate all hardware modules''' 
*'''LCD: Testing & Validation of the LCD UI and display vehicle status information''' 
*'''Android: Send car location to the app and checkpoints received to Geo module''' 
*'''Motor: Optimize PID control by accelerating/decelerating as instructed by Driver''' 
*'''Bridge: Configure HC-05 for auto reconnection if bluetooth communication disconnects''' 
*'''Add multiple debug messages and transmit on CAN'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''11'''
| style="text-align:center;" |'''04/21/2020'''
| style="text-align:center;" |'''04/27/2020'''
|
*'''Android: Send additional vehicle status information from RC car to the Application for display''' 
*'''Android: Finalize User Interface Design and Icon''' 
*'''Continuously test the whole system and handling of corner cases (outside).'''
*'''Finalize RC Car For Project Proto 1'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''12'''
| style="text-align:center;" |'''04/28/2020'''
| style="text-align:center;" |'''05/04/2020'''
|
*'''Gitlab: Push final code'''
*April 28th: Project Proto 1
*'''Finalize RC Car for Project Demo'''
*May 1st: Project Presentation
*'''Finalize RC Car for Project Proto 2'''
|
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
*'''Completed'''
|-

! scope="row"| '''13'''
| style="text-align:center;" |'''05/05/2020'''
| style="text-align:center;" |'''05/21/2020'''
|
* '''Complete Individual Contribution Peer Grading'''
* '''Review and Complete Wiki Project Page'''
|
*'''Completed'''
*'''In Progress'''
|-
|}

 

== '''Bill Of Materials''' ==
{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Item#
! scope="col"| Part Description
! scope="col"| Part Model & Vendor
! scope="col"| Quantity
! scope="col"| Cost in USD
|-
! scope="row"| 1
| '''Microcontroller Boards'''
| SJ2 Boards (Purchased from Preet Kang)
| 4
| $200.00
|-
! scope="row"| 2
| '''CAN Transceivers'''
| [https://www.waveshare.com/sn65hvd230-can-board.htm Waveshare SN65HVD230]
| 12
| $54.48
|-
! scope="row"| 3
| '''RC Car'''
| [https://www.amazon.com/Traxxas-Slash-Course-2-4GHZ-Vehicle/dp/B01DU474B0/ref=sr_1_3?ie=UTF8&qid=1474747759&sr=8-3&keywords=Traxxas+1%2F10+slash+2wd Traxxas 2WD RTR with 2.4Ghz Radio]
| 1
| $260.00
|-
! scope="row"| 4
| '''Lithium-Ion Battery'''
| [https://www.rcsuperstore.com/traxxas-7600mah-2s-7-4v-25c-id-lipo-battery-pack/ Traxxas 7600mAh 2S 7.4V 25C iD LiPo Battery Pack]
| 1
| $75.00
|-
! scope="row"| 5
| '''Lithium-Ion Battery Charger'''
| [https://www.amazon.com/Traxxas-2970-EZ-Peak-Charger-Identification/dp/B00OAFYLJC/ref=pd_bxgy_21_img_2?ie=UTF8&psc=1&refRID=JVX791WVV9Y8T9DW92KW Traxxas 2970 EZ-Peak Plus 4-Amp NiMH/LiPo Fast Charger]
| 1
| $50.00
|-
! scope="row"| 6
| '''Compass Breakout Board'''
| [https://www.dfrobot.com/product-1275.html DFRobot CMPS11 Compass]
| 1
| $29.99
|-
! scope="row"| 7
| '''Bluetooth Breakout Board'''
| [https://www.amazon.com/HC-05-Bluetooth-Pass-through-Wireless-Communication/dp/B01G9KSAF6/ref=sr_1_4?ie=UTF8&qid=1507077325&sr=8-4&keywords=arduino+bluetooth+hc-05 DSD TECH Bluetooth HC-05]
| 1
| $8.49
|-
! scope="row"| 8
| '''LIDAR Sensor'''
| [https://www.amazon.com/RPLiDAR-A1M8-Degree-Laser-Scanner/dp/B07H7X3SFF/ref=sr_1_fkmrnull_1?crid=2FSUI76G4UA8K&keywords=rplidar+a1m8+-+360+degree+laser+scanner+development+kit&qid=1552764172&s=gateway&sprefix=RPlidar%2Caps%2C263&sr=8-1-fkmrnull SEEED STUDIO RPLIDAR A1M8]
| 1
| $109.99
|-
! scope="row"| 9
| '''RPM Sensor'''
| [https://www.amazon.com/Traxxas-6520-RPM-Sensor-long/dp/B006IRXEZM Traxxas 6520 RPM Sensor]
| 1
| $13.70
|-
! scope="row"| 10
| '''GPS Breakout Board'''
| [https://www.adafruit.com/product/746 Adafruit Ultimate GPS Breakout v3]
| 1
| $44.30
|-
! scope="row"| 11
| '''LCD Display'''
| [https://4dsystems.com.au/ulcd-32ptu 4Dsystems 3.2 TFT-LCD ULCD-32PTU]
| 1
| $79.00
|-
! scope="row"| 12
| '''Ultrasonic Sensors'''
| [https://www.amazon.com/gp/product/B01COSN7O6/ ELEGOO HC-SR04 Ultrasonic Module]
| 5
| $12.00
|-
! scope="row"| 13
| '''GPS Antenna'''
| [https://www.amazon.com/dp/B07RRT615K/ GPS Antenna A1-UX]
| 1
| $10.98
|-
! scope="row"| 14
| '''PCB Fabrication'''
| [https://jlcpcb.com/ JLCPCB]
| 5
| $40.15
|-
! scope="row"| 15
| '''Miscellaneous'''
| [https://www.amazon.com Amazon],[https://www.mouser.com/ Mouser Electronics],[https://www.digikey.com/ Digikey],[https://anchor-electronics.com/ Anchor Electronics]
| ~
| $48.07
|-
! scope="row"|
|
|
| '''Total'''
| '''$1036.15'''
|-

|}

 

== '''Printed Circuit Board''' ==

=== Design And Architecture ===
The complete PCB (for boards and hardware peripherals) was designed using EasyEDA online software. The 4 nodes will be communicating via CAN bus and other peripherals are connected to the PCB via headers.

=== Power Section===
We have 2 power banks supplying our system. And the Servo Motor, RPM sensor and DC rear Motor (via ESC) are powered using LiPo battery (6 volts).
* Power bank #1 - Subset 2

* Power bank #2 - Subset 1, Subset 3, Bluetooth

'''NOTE:'''

'''Subset 1:'''
1. LIDAR
2. LCD
3. Compass

'''Subset 2:'''
1. Motor node
2. Driver node
3. BS node

'''Subset 3:'''
1. Geo node
2. Back ultrasonic sensor

=== Fabrication ===
* PCB was sent to fabrication to JLCPCB China which provided PCB with MOQ of 5 and 2 layers of PCB with common grounded the entire copper area.
'''DRC elements'''
* Track Width = 12
* Clearance = 10
* Via Diameter = 24
* Via Drill Diameter = 12

=== Challenges ===
* Auto-routing gave lot of challenges (only ~60% success) and sometimes the online server even crashes and faces downtime. Even local routing had lot of issues. So make sure to plan your design accordingly.
* We started our PCB design well ahead of the project. So lot of pre-planning had to be done with regard to final hardware and placement of components in order to avoid spending extra time and money while re-ordering.
* The PCB went through a lot of internal revisions even before placing order. This was time-consuming.

'''Other hardware challenges:'''
* Figuring out why various hardware peripherals (GPS, Bluetooth, LIDAR and Ultrasonic sensor) started to malfunction (devices were on but values were either inconsistent / not occurring), took a lot of time to debug. It was due to insufficient power.

 

[[File:CMPE243 S20 T2 EasyEDA.png|1040x1200px|thumb|center|PCB Layout Design in EasyEDA]]
[[File:CMPE243 S20 T2 PCB SCHEMATIC.jpg|1041x550px|thumb|center|PCB Schematic]]

<div><ul>
<li style="display: inline-block;"> [[File:CMPE243 S20 T2 PCBFRONT.jpg|thumb|none|600px|PCB Top Layer]] </li>
<li style="display: inline-block;"> [[File:CMPE243 S20 T2 PCBBACK.jpg|thumb|none|600px|PCB Bottom Layer]] </li>
</ul></div>

 

== '''CAN Communication''' ==
<Talk about your message IDs or communication strategy, such as periodic transmission, MIA management, etc.>

=== Hardware Design ===
<Show your CAN bus hardware design>

=== DBC File ===

DBC FILE: [https://gitlab.com/coder137/can-ster_truck/-/blob/dbc-improvements/projects/lpc40xx_freertos/project.dbc Gitlab]

<pre>
VERSION ""

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

BS_:

BU_: DBG DRIVER IO MOTOR SENSOR GEO

BO_ 100 DRIVER_HEARTBEAT: 1 DRIVER
SG_ DRIVER_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" GEO,MOTOR,SENSOR

BO_ 101 GEO_HEARTBEAT: 1 GEO
SG_ GEO_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,MOTOR,SENSOR

BO_ 102 MOTOR_HEARTBEAT: 1 MOTOR
SG_ MOTOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,SENSOR

BO_ 103 SENSOR_HEARTBEAT: 1 SENSOR
SG_ SENSOR_HEARTBEAT_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER,GEO,MOTOR

BO_ 200 MOTOR_STEERING: 1 DRIVER
SG_ MOTOR_STEERING_direction: 0|8@1- (1,0) [-2|2] "" MOTOR

BO_ 210 DRIVER_COORDINATES: 8 DRIVER
SG_ DRIVER_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
SG_ DRIVER_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 220 MOTOR_SPEED: 1 DRIVER
SG_ MOTOR_SPEED_processed: 0|8@1- (1,0) [-3|3] "" MOTOR

BO_ 300 GEO_DEGREE: 8 GEO
SG_ GEO_DEGREE_current: 0|32@1+ (0.000001,0) [0|360] "degrees" DRIVER
SG_ GEO_DEGREE_required: 32|32@1+ (0.000001,0) [0|360] "degrees" DRIVER

BO_ 310 GEO_DESTINATION_REACHED: 1 GEO
SG_ GEO_DESTINATION_REACHED_cmd: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 400 MOTOR_SPEED_FEEDBACK: 4 MOTOR
SG_ MOTOR_SPEED_current: 0|32@1+ (0.1,0) [0|60] "kph" DRIVER

BO_ 500 SENSOR_BT_COORDINATES: 8 SENSOR
SG_ SENSOR_BT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" GEO
SG_ SENSOR_BT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" GEO

BO_ 510 SENSOR_SONARS: 8 SENSOR
SG_ SENSOR_SONARS_left: 0|21@1+ (0.001,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_right: 21|21@1+ (0.001,0) [0|0] "cm" DRIVER
SG_ SENSOR_SONARS_middle: 42|21@1+ (0.001,0) [0|0] "cm" DRIVER

BO_ 520 SENSOR_LIDAR: 8 SENSOR
SG_ SENSOR_LIDAR_middle: 0|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_slight_left: 16|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_slight_right: 32|16@1+ (1,0) [0|0] "cm" DRIVER
SG_ SENSOR_LIDAR_back: 48|16@1+ (1,0) [0|0] "cm" DRIVER

BO_ 530 MOTOR_KEY: 1 SENSOR
SG_ MOTOR_KEY_val: 0|8@1+ (1,0) [0|0] "" DRIVER

BO_ 900 GEO_CURRENT_COORDINATES: 8 GEO
SG_ GEO_CURRENT_COORDINATES_latitude: 0|32@1- (0.000001,-90) [-90|90] "degrees" DBG
SG_ GEO_CURRENT_COORDINATES_longitude: 32|32@1- (0.000001,-180) [-180|180] "degrees" DBG

BO_ 901 GEO_DISTANCE_FROM_DESTINATION: 4 GEO
SG_ GEO_distance_from_destination: 0|32@1+ (0.001,0) [0|0] "meters" DBG

BO_ 902 MOTOR_INFO_DBG: 4 MOTOR
SG_ MOTOR_INFO_DBG_rps: 0|16@1+ (1,0) [0|0] "" DBG
SG_ MOTOR_INFO_DBG_pwm: 16|16@1+ (0.001,0) [0|0] "" DBG

BO_ 903 LIPO_BATTERY_VOLTAGE_DBG: 4 MOTOR
SG_ LIPO_BATTERY_VOLTAGE_val: 0|32@1+ (0.01,0) [0|0] "volts" DBG

BO_ 904 CURRENT_CHECKPOINT_DBG: 1 GEO
SG_ CURRENT_CHECKPOINT_val: 0|8@1+ (1,0) [0|0] "" DBG

CM_ "--BU (Network Node) Information--";
CM_ BU_ DRIVER "The driver controller of the car";
CM_ BU_ GEO "The geo controller of the car";
CM_ BU_ MOTOR "The motor controller of the car";
CM_ BU_ SENSOR "The sensor controller of the car";

CM_ "--BO (Message) Information--";
CM_ BO_ 100 "Driver Sync message used to synchronize the controllers";
CM_ BO_ 101 "Geo Sync message used to synchronize the controllers";
CM_ BO_ 102 "Motor Sync message used to synchronize the controllers";
CM_ BO_ 103 "Sensor Sync message used to synchronize the controllers";

CM_ BO_ 200 "Steering direction values sent by Driver Node to Motor Node";
CM_ BO_ 210 "Driver Destination coordinates sent by Driver Node";
CM_ BO_ 220 "Required motor speed computed from Driver Node to Motor Node";

CM_ BO_ 300 "Current and computer/required degree values sent by Geo Node";
CM_ BO_ 310 "Indicator signal to check if the RC car has reached the destination";

CM_ BO_ 400 "Current motor info (rps and kph) sent as feedback to the Driver Node";

CM_ BO_ 500 "Coordinate BT values (destination coordinates) sent by Sensor Node";
CM_ BO_ 510 "LIDAR - Distance from obstacle detected in each sector";
CM_ BO_ 520 "Ultrasonic Sensor - Distance from obstacle detected by each sensor";
CM_ BO_ 530 "Start/Stop signal from the Bluetooth app";

CM_ BO_ 900 "Destination coordinates for BUSMASTER debugging";
CM_ BO_ 901 "Distance from destination";
CM_ BO_ 902 "Supplied PWM value to the motor and its RPM";
CM_ BO_ 903 "LIPO Battery Voltage";
CM_ BO_ 904 "Current checkpoint of the car";

CM_ "--SG (Signal) Information for Heartbeats--";
CM_ SG_ 100 DRIVER_HEARTBEAT_cmd "Heartbeat command from the driver node";
CM_ SG_ 101 GEO_HEARTBEAT_cmd "Heartbeat command from the geological node";
CM_ SG_ 102 MOTOR_HEARTBEAT_cmd "Heartbeat command from the motor node";
CM_ SG_ 103 SENSOR_HEARTBEAT_cmd "Heartbeat command from the sensor node";

CM_ "--SG (Signal) Information for DRIVER Node--";
CM_ SG_ 200 DRIVER_STEERING_direction "Calculated Driver Steering values (-2,2) for Motor";
CM_ SG_ 210 DRIVER_COORDINATES_latitude "Destination Latitude coordinate";
CM_ SG_ 210 DRIVER_COORDINATES_longitude "Destination Longitude coordinate";
CM_ SG_ 220 MOTOR_SPEED "Calculated Driver speed values (-3,3) for Motor";

CM_ "--SG (Signal) Information for GEO Node--";
CM_ SG_ 300 GEO_DEGREE_current "Current Geo Degree relative to true north";
CM_ SG_ 300 GEO_DEGREE_required "Calculated Geo Degree computed by Haversine Formula";
CM_ SG_ 310 GEO_DESTINATION_REACHED "Indicator signal to check if the RC car has reached the destination";

CM_ "--SG (Signal) Information for MOTOR Node--";
CM_ SG_ 400 MOTOR_SPEED_FEEDBACK "Feedback speed (kph) sent by Motor Node";

CM_ "--SG (Signal) Information for SENSOR Node--";
CM_ SG_ 500 SENSOR_BT_COORDINATES_latitude "Destination Latitude received over Bluetooth";
CM_ SG_ 500 SENSOR_BT_COORDINATES_longitude "Destination Longitude received over Bluetooth";
CM_ SG_ 510 SENSOR_SONARS_left "Ultrasonic Sensor attached to the left side";
CM_ SG_ 510 SENSOR_SONARS_right "Ultrasonic Sensor attached to the right side";
CM_ SG_ 510 SENSOR_SONARS_middle "Ultrasonic Sensor attached to the middle";
CM_ SG_ 510 SENSOR_SONARS_back_left "Ultrasonic Sensor attached to the back left side";
CM_ SG_ 510 SENSOR_SONARS_back_right "Ultrasonic Sensor attached to the back right side";
CM_ SG_ 520 SENSOR_LIDAR_middle "Lidar sensing the middle sector (-15 to 15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_left "Lidar sensing the slight left sector (-45 to -15 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_slight_right "Lidar sensing the slight right sector (15 to 45 degrees)";
CM_ SG_ 520 SENSOR_LIDAR_back "Lidar sensing the back of the car (165 to 195 degrees)";
CM_ SG_ 530 MOTOR_KEY_val "1 -> Start the motor from the app, 0 -> Stop";

CM_ SG_ 900 GEO_CURRENT_COORDINATES_latitude "Current Latitude";
CM_ SG_ 900 GEO_CURRENT_COORDINATES_longitude "Current Longitude";
CM_ SG_ 901 GEO_distance_from_destination "Distance from destination";
CM_ SG_ 902 MOTOR_INFO_DBG_rps "Current RPS value of the motor";
CM_ SG_ 902 MOTOR_INFO_DBG_pwm "Supplied motor PWM value";
CM_ SG_ 903 LIPO_BATTERY_VOLTAGE_val "LIPO Battery Voltage";
CM_ SG_ 904 CURRENT_CHECKPOINT_val "Current checkpoint of the car";

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

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

BA_ "GenMsgCycleTime" BO_ 100 1000;
BA_ "GenMsgCycleTime" BO_ 200 50;
BA_ "FieldType" SG_ 100 DRIVER_HEARTBEAT_cmd "DRIVER_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 102 GEO_HEARTBEAT_cmd "GEO_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 103 MOTOR_HEARTBEAT_cmd "MOTOR_HEARTBEAT_cmd";
BA_ "FieldType" SG_ 104 SENSOR_HEARTBEAT_cmd "SENSOR_HEARTBEAT_cmd";

BA_ "FieldType" SG_ 200 MOTOR_STEERING "MOTOR_STEERING";
BA_ "FieldType" SG_ 230 MOTOR_SPEED_val "MOTOR_SPEED_val";
BA_ "FieldType" SG_ 310 GEO_DESTINATION_REACHED_cmd "GEO_DESTINATION_REACHED_cmd";

VAL_ 100 DRIVER_HEARTBEAT_cmd 2 "DRIVER_HEARTBEAT_cmd_REBOOT" 1 "DRIVER_HEARTBEAT_cmd_SYNC" 0 "DRIVER_HEARTBEAT_cmd_NOOP" ;
VAL_ 101 GEO_HEARTBEAT_cmd 2 "GEO_HEARTBEAT_cmd_REBOOT" 1 "GEO_HEARTBEAT_cmd_SYNC" 0 "GEO_HEARTBEAT_cmd_NOOP";
VAL_ 102 MOTOR_HEARTBEAT_cmd 20 "MOTOR_HEARTBEAT_cmd_REBOOT" 10 "MOTOR_HEARTBEAT_cmd_SYNC" 0 "MOTOR_HEARTBEAT_cmd_NOOP" ;
VAL_ 103 SENSOR_HEARTBEAT_cmd 200 "SENSOR_HEARTBEAT_cmd_REBOOT" 100 "SENSOR_HEARTBEAT_cmd_SYNC" 0 "SENSOR_HEARTBEAT_cmd_NOOP" ;

VAL_ 200 MOTOR_STEERING_direction -2 "MOTOR_STEERING_hard_left" -1 "MOTOR_STEERING_slight_left" 0 "MOTOR_STEERING_straight" 1 "MOTOR_STEERING_slight_right" 2 "MOTOR_STEERING_hard_right";
VAL_ 220 MOTOR_SPEED_processed -3 "MOTOR_SPEED_reverse_fast" -2 "MOTOR_SPEED_reverse_medium" -1 "MOTOR_SPEED_reverse_slow" 0 "MOTOR_SPEED_neutral" 1 "MOTOR_SPEED_forward_slow" 2 "MOTOR_SPEED_forward_medium" 3 "MOTOR_SPEED_forward_fast";
VAL_ 310 GEO_DESTINATION_REACHED_cmd 1 "GEO_DESTINATION_REACHED_cmd_REACHED" 0 "GEO_DESTINATION_REACHED_cmd_NOT_REACHED";
</pre>

 

== '''Motor Controller''' ==
<Picture and link to Gitlab>

This controller is used to control the components of the car-related to motor. We can control the speed and steering of the car having interfaced with various components with the SJ-2 board. The servo motor is controlled via PWM and is used to set the steering direction of the car. The DC motor is controlled by the Electronic Speed Controller (ESC) via PWM for speed. We read the speed of the car by using an RPM sensor. By using the RPM sensor values, a feedback loop has been designed to regulate the speed of the car. A state machine has been designed to manage the forward and backward movements of the car.
Additionally, a voltage divider circuit has been implemented to read the battery voltage. All motor functionality and CAN message communication is run at 10 Hz.

=== Hardware Design ===

The following diagram details the hardware implementation of the motor module with the SJTwo board:
Hardware Interface
- Servo Motor
The servo motor responds to PWM pulses. It has three pins namely Vcc, PWM Input Signal, and GND. The servo is powered using 6V from the car battery. Based on the PWM signal supplied from the SJTwo board the front wheels are turned.
- Electronic Speed Controller (ESC)
The ESC is used to control the DC motor. It is supplied power using the 7.4 V LiPo battery. It has three pins namely Vout, PWM Input Signal, and GND. Based on the PWM input signal, the speed and forward, neutral, and backward movements of the car is changed. Vout is given to the RPM sensor and Servo motor.
- DC Motor
The DC motor is controlled using the ESC. It has two pins, a positive and negative terminal. A PWM signal wire is connected to the microcontroller and the required current is provided by the LiPo battery and the ESC. The DC motor is controlled using PWM at 10Hz.

[[File:CMPE243_S20_T2_Canster_Truck_Motor_Hardware.png|thumb|center|750px| Motor Hardware System]]

Note: First calibrate the DC motor or the motor will not respond to your PWM pulses. For help with calibration go to this [https://traxxas.com/support/Programming-Your-Traxxas-Electronic-Speed-Control website]

- RPM Sensor

The RPM sensor is used to get the current speed of the car. We use the info for creating a feedback loop (PID) for maintaining the speed of the car in uphill and downhill situations. The RPM sensor mounts on the rear DC motor shaft compartment with a special assembly also provided by Traxxas. The magnet which attached to the inner gear generates a pulse each rotation. The sensor works on the hall effect principle where it provides a current across its terminal when placed in a magnet's field. The RPM sensor has three pins namely Vcc, Signal, and GND.

- Battery Voltage Divider Circuit
- (Need Niket’s help)

=== Software Design ===

The software for the motor node was divided into multiple files and made modular to improve readability and understanding of the complex logic involved. The main code modules are for:
• Servo Motor
• Electronic Speed Controller
• RPM Sensor
• Motor Wrapper
• Battery Voltage

The motor wrapper module is used to wrap all the code from the esc, servo, and rpm modules into simple to use functions to be called in the periodic tasks.
• Servo Motor
It uses the steering value sent from the driver (-2 to 2) and matches it to the appropriate PWM value for steering. This code module is run at 10Hz.
<pre>
void servo__steer_processor(int16_t steering_value) {
switch (steering_value) {
case MOTOR_STEERING_hard_left:
servo__steer_hard_left();
break;
case MOTOR_STEERING_slight_left:
servo__steer_soft_left();
break;
case MOTOR_STEERING_straight:
servo__steer_straight();
break;
case MOTOR_STEERING_slight_right:
servo__steer_soft_right();
break;
case MOTOR_STEERING_hard_right:
servo__steer_hard_right();
break;
default:
printf("\nDid not receive steering value");
}
}
</pre>
• Electronic Speed Controller

This code module is used to control the DC motor. It receives the motor direction value from the driver and sets the appropriate PWM value. Based on the value the motor is commanded to move the car forward or backwards. A switch case is implemented to set PWM values for movement in different directions along with different speeds.
<pre>
void esc__direction_processor(int16_t direction_value) {
desired_direction_value = direction_value;
switch (direction_value) {
case MOTOR_SPEED_reverse_fast:
esc__reverse_fast();
break;
case MOTOR_SPEED_reverse_medium:
esc__reverse_medium();
break;
case MOTOR_SPEED_reverse_slow:
esc__reverse_slow();
break;
case MOTOR_SPEED_neutral:
esc__neutral();
break;
case MOTOR_SPEED_forward_slow:
esc__forward_slow();
break;
case MOTOR_SPEED_forward_medium:
esc__forward_medium();
break;
case MOTOR_SPEED_forward_fast:
esc__forward_fast();
break;

default:
printf("\nDid not receive direction and speed value");
}
}
</pre>

There is also a feedback loop to control the speed. The ESC code depends on the rpm sensor code for the current speed values.
<pre>
double current_speed = get_speed_kph();
double desired_speed = desired_speed_kph;
float adjusted_duty_cycle = 0.0;
adjusted_duty_cycle = duty_cycle + (speed_to_pwm_adjustment(desired_speed, current_speed));
</pre>

[[File:CMPE243_S20_T2_Canster_Truck_Motor1.png|thumb|center|400px| Motor Flowchart 1]]

• RPM Sensor
This code module is used to get current speed data from the RPM sensor. It is based on interrupts. When the wheel rotates once, we get one pulse due to the magnet installed. This pulse generates a falling edge interrupt during which we increment the pulse counter. Since, this code is run at 1Hz we collect the number of pulses generated every one second. This gives us the number of rotations per second using which we can calculate the speed in kph.
<pre>
float rpm__calculate_speed_kph() {
uint16_t rotation_per_sec = pulse_count;
pulse_count = 0;
speed_kph = ((CIRCUMFERENCE_METER * rotation_per_sec) * (MPS_TO_KPH_CONVERSION_FACTOR)) / GEAR_RATIO;
return speed_kph;
}
</pre>

• Motor Wrapper
As mentioned above, the main function of this code module is to wrap all the other code modules and call the right functions at the appropriate frequency. The motor wrapper code also includes a state machine for ensuring a smooth transition between forward to backward state and vice versa. In order to achieve a smooth transition, a series of PWM pulses must be generated at the right time. For example, when the motor is moving from forward to backward state, a reverse value must be given first followed by at least three neutral values, and then continue with reverse values.

[[File:CMPE243_S20_T2_Canster_Truck_Motor2.png|thumb|center|400px| Motor Flowchart 2]]

• LIPO Battery Voltage:
The LIPO Battery Voltage was calculated using ADC in Burst Mode. A LIPO Hardware module was created for the same which contained two functions, <code>lipo__init</code> and <code>lipo__get_voltage</code>.

LIPO Initialization

The LIPO Initialization phase initializes the ADC, Enables Burst mode on the ADC pins and configures the Alternate Function Registers for the same.

LIPO Get Voltage

We read the raw ADC value from the LPC Hardware register. This value will be from 0 - 3.3V. However due to our voltage divider configuration the max voltage that we should theoretically get is 2.1V. This means that 2.1V corresponds to 7.4V of the LIPO Battery voltage.

The formula used is
<code>(raw_adc_value * MAX_LIPO_BATTERY_VOLTAGE_VALUE) / MAX_LIPO_ADC_VALUE</code>

=== Technical Challenges ===
<ol>
<li>Changing movements of the car from Forward to Backward and vice versa
If you just change the PWM value from say 16 (Forward) to 14(Backward), the DC motor will just stop and will not make wheels turn reverse. We discovered this problem quite late as during the initial testing we had always run the car from the start with either forward or reverse but never tried changing the direction during run-time.
Solution: The motor requires a series of PWM pulses which is specific to the car to transition from forward mode to reverse mode. In our case we had to give the PWM pulses in the following sequence. Suppose,
<ol>
<li> Forward (16) (callback_count=0)</li>
<li> Forward (16) (callback_count =1)</li>
<li> Reverse (14) (callback_count =2)</li>
<li> Neutral (15) (callback_count = 3)</li>
<li> Neutral (15) (callback_count = 4)</li>
<li> Neutral (15) (callback_count = 5)</li>
<li> Reverse (14) (callback_count = 6)</li>
<li> Continue reverse</li>
</ol>
Similarly, the reverse to forward can also be implemented.
<li>DC motor shooting off when there is an improper ground connection
When we connected the battery voltage circuit for reading the voltage from the battery, the motor would randomly shoot off every now and then.
Solution: Connect the voltage divider circuit to the common ground rather than taking the ground from the ESC.</li>
</ol>

<HR>
 

== '''Geological Controller''' ==

<Picture and link to Gitlab>

===Messages===
*GEO_HEARTBEAT: Used to check for MIA by other nodes. Highest priority message for GEO Node

*GEO_DEGREE: Sends the current degree relative to the North Pole computed by the Compass and the Required degree relative to the North Pole computed by Bearing Angle using the Current Coordinate and Destination Coordinate.

*GEO_DESTINATION_REACHED: Sets a flag, 0 for destination not reached and 1 for destination reached

*GEO_CURRENT_COORDINATES: Debug Message used to send the Current GPS Coordinates

*GEO_DISTANCE_FROM_DESTINATION: Debug message used to send the Distance from Destination

*CURRENT_CHECKPOINT_DBG: Debug message used to check which checkpoint is being navigated to

=== Hardware Design ===

[[File:CMPE243_S20_T2_GEO1.png|thumb|center|650px| Geological Diagram]]

=== Software Design ===
=====Overview=====
*Inside the `periodic_callback__initialize`
**Initialize the CAN BUS
**Initialize the GPS

*Inside the `periodic_callback__1hz`
**Handle all MIA (from other Nodes)
**Update GPS LED when init and in case of failure
**Compute the GEOLOGIC for Waypoints algorithm once every second (1000 ms)

*Inside the `periodic_callback__10hz`
**Handle CAN Incoming messages (Decode)
**Transmit CAN Geo messages (Encode and send)
**Compute the GPS Coordinate

=====Compass I2C Driver=====
An online datasheet resource was used to work with the Compass (https://www.robot-electronics.co.uk/htm/cmps11i2c.htm)
Initially the Compass I2C Driver was tested using the Terminal I2C Helper built by our Professor Preetpal Kang. Using this resource we were quickly able to read various I2C Registers and display it onto the terminal.

For our project the only required part of the Compass was the 16-bit Compass Bearing value (0-3599) i.e 0-359.9 degree values. These values were stored in the 2nd and 3rd register (Register 2 being the High Byte).
Once the raw data was received over I2C we could easily combine the data

<pre>
uint16_t bearing_value = (Reg2 << 8) | Reg3;
float rval = bearing_value / 10.0;
return rval;
</pre>
The returned value were transmitted to the Driver Node to compute its steering based on the required Bearing Angle.

=====GPS Initialization=====
GPS Initialization activates the Hardware GPIO (RX and TX), FreeRTOS Queue for UART Interrupts (UART Module) and Line Buffer Module to parse each GPS line.

=====GPS Data Parsing=====
The GPS Hardware module transmits an NMEA string over UART to the SJTwo Board. We read each character one by one and add it to the Line Buffer module.
Inside its computation loop, the Line Buffer module checks if a newline character has been received.
When a newline character has been received the entire string is extracted from the line buffer module and parsed according to its identifier ($GPRMC, $GPGGA) received and parsed into individual tokens.
For our purposes the $GPRMC NMEA string was the most appropriate and it helped us extract the Current Latitude Longitude as well as the Valid/Invalid tag for the Canster Truck.

=====GPS LED Indication for debugging=====

A simple module that checks for the GPRMC GPS Message and extracts the A or V valid (Tag). If $GPRMC NMEA string is valid, LED is set, else LED is reset. This gives us onsite debugging capabilities to know if GPS has locked onto a satellite signal.

=====GEO Logic Module Computation=====
The GEO Logic Module computes the Bearing Angle, Haversine Distance as well as the Waypoints algorithm.

'''Bearing Angle:'''

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

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

Since atan2 returns values in the range -π ... +π (that is, -180° ... +180°), to normalize the result to a compass bearing (in the range 0° ... 360°, with −ve values transformed into the range 180° ... 360°), convert to degrees and then use (θ+360) % 360, where % is (floating point) modulo.
For final bearing, simply take the initial bearing from the endpoint to the start point and reverse it (using θ = (θ+180) % 360).

The above article reference gives us the required bearing angle that our car must align itself to, to reach a particular destination coordinate from its current coordinate.
The Steering of the Canster Truck depends on the above-computed angle values.

'''Haversine Distance Formula:'''

This uses the ‘haversine’ formula to calculate the great-circle distance between two points – that is, the shortest distance over the earth’s surface – giving an ‘as-the-crow-flies’ distance between the points (ignoring any hills they fly over, of course!).

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);
note that angles need to be in radians to pass to trig functions!

The above formula is used to calculate the distance between the source coordinate (received via GPS) and the destination coordinate.
Later this was used to compute the distance between source coordinate and each individual checkpoint to traverse the shortest distance.

'''Waypoints Algorithm:'''

The Waypoints algorithm that was chosen was a slightly modified version of Djikstra’s Algorithm.
3 values were calculated before the final computation
- Distance between source and final destination (DISTsd)
- Distance between source and each individual checkpoint (DISTsc)
- Distance between each individual checkpoint and the final destination. (DISTcd)
If DISTsd was lesser than DISTcd, this checkpoint was discarded (we continue in the loop). Since we would be moving in the opposite direction, rather than towards the final destination.
If DISTsd was greater than DISTcd, then we checked the nearest checkpoint to the source.
The minimum value was set initial that was equal to DISTsd.
If DISTsc was lesser than the minimum value stored, DISTsc would become the new minimum value, and the checkpoint index and coordinates would be appropriately stored and returned from the function.
In this way we would navigate to the nearest checkpoint from the source, while also making sure NOT to travel in the opposite direction.
This logic is recomputed only when we reach the checkpoint selected and the algorithm runs again to find the next checkpoint that we need to navigate to.

=====CAN Decode Destination Coordinates=====
Destination Coordinates are received from the Bridge and Sensor Node and transmitted over the CAN Bus. The value is decoded and stored in the GEO Logic Module.
This is a very important value since our entire GEO Logic calculations are based on the Destination Coordinate.

=====CAN Encode and Send=====

The main messages that were transmitter are
#Geo Degree
#Geo Destination Reached
#Distance from Destination Debug and Checkpoint Index debug

'''Geo Degree Computation as per Waypoints Algorithm:'''

Geo Degree was computed as per the current coordinates and the most recently computed checkpoint coordinates. This bearing angle calculation w.r.t computed checkpoint would continue till we do not reach that particular checkpoint.
Once we reach the computed checkpoint, Waypoint algorithm is recomputed as per the process mentioned above and the algorithm runs again.

'''Geo Destination Reached:'''

An Area of around 4 meters was set around the destination coordinate to check if the destination had been reached.
This measurement was taken into consideration to allow for the loss in precision when transmitting data over CAN as well as any irregularities that might occur when getting values from the GPS.
Having an area of 4 meters was very accurate for all of our test runs.

'''Geo Distance from Destination Debug and Checkpoint Index Debug:'''

Getting debug information was very critical to speed up our development process. In this case we could actively see if our algorithm worked properly.
The Geo Distance from Destination was used to see if we were moving closer to our destination or veering further away from it.
The Checkpoint Index was used to see which checkpoint index we were traveling to. By knowing the placements of the Individual checkpoints we could manually as well as programmatically (via Android application) verify the working of our Canster Truck.

=== Technical Challenges ===
#DBC Challenge for GEO Coordinates -> Could not encode more than 5-6 decimal places at a time, on later investigation we found that the 10000 is an int value, however 100000 overflows the int value.
#Creating an efficient algorithm for Waypoints, O(n) complexity.
#Getting appropriate fixes for GPS when not in a completely open space.
#GPS used to fluctuate or stop giving values when Battery voltage went below a particular threshold. Always supply 3.3V constantly at a good amperage.

<HR>
 

== '''Sensor [Bridge and Sensor Controller]''' ==
<Picture and link to Gitlab>

==='''Ultrasonic Sensor'''===
====Hardware Design====
This sensor uses an ultrasonic beam to measure the distances. Based on the time taken between when the beam is sent and received back to the sensor, the distance is calculated in the node.
Apart from 5v and GND, this sensor has 2 pins ECHO and TRIG which are interfaced with the SJ-Two board via GPIO.

[[File:CMPE243_S20_T2_CansterTruck_ultrasonic_sensor.jpg|thumb|center|300px| Ultrasonic Sensor Diagram]]

====Software Design====
* Init the GPIO pin connected to TRIG of the sensor as output and for ECHO as an input port.
* Attach the interrupt on the ECHO input port.
* Store the system_clock_count before setting the trigger pulse and then set the pulse. Also keep monitoring the input port.
* Take the system_clock_count at the instant of receiving the interrupt.
Distance = (system_clock_count_at_trig - system_clock_count_after_at_echo) / 57.14

==='''Lidar Sensor'''===
====Hardware Design====
The RPLidar sensor can be powered from a 5-volt source and uses UART communication to receive commands and transmit data. It has seven pins to interface with. Two sets of the pins (four total) are for power and ground. The remaining three are for UART receive and transmit, and for making the lidar’s motor spin.

[[File:CMPE243_S20_T2_Canster_Truck_RPLidar_A1.JPG|thumb|center|300px| RPLidar A1]]

====Software Design====
In terms of the lidar, the SJ2 initializes GPIO, UART, and memory for storing the measurement values. After initialization, the command to begin scanning is sent. Here, we wait for the lidar to send a response packet, letting the host (SJ2 board) know it received the command. The response packet the lidar sends will be 7 bytes. If the correct 7 bytes are not received, the command will be sent again.

[[File:CMPE243_S20_T2_Canster Truck_Lidar_flow.jpeg|thumb|center|200px| Lidar Flow]]

Following the response packet, the lidar begins sending 5-byte measurement data. Each sample contains a distance measurement (in millimeters) and the angle (with respect to the lidar) in which it was taken. The data packet structure is shown in the following figure. In addition to containing the distance and angle, the packet includes a quality value, to indicate the reliability of the measurement, and three check bits (S, ~S, and C). As the data is received via UART, we wait until we have 5 bytes before continuing to process. Before processing the 5 bytes after receiving them, the check bits are confirmed to be correct. If they are incorrect, it will not be processed and we will wait for another sample to be received.

[[File:CMPE243_S20_T2_Canster Truck_DataPacketStructure.JPG|thumb|center|200px| Data Packet Structure]]

In the case the sample is correct, each measurement value that is in a direction of interest will be placed in an array designated to one of four directions (left, right, front, rear). Each of these directions have their own sector in the lidar’s 360-degree view.
*Right sector: 11°-30°
*Rear sector: 170°-190°
*Left sector: 330°-349°
*Front sector: 350°-370° (or 10°)

The arrays mentioned will hold roughly 20 measurements, which are every degree in the sector. In the event, objects are too far to measure, the lidar will report 0 mm. distance. Since there is no measurable obstacle, a “large” distance value of 3000 mm. is placed in the array. The smallest distance value will be taken from each array and reported to the driver node for obstacle avoidance.

=== Technical Challenges ===
====Ultrasonic====
====Lidar====
*'''Datasheet not 100% clear:''' The correct datasheet for the was a bit difficult to obtain, and the manufacturer needed to be contacted. The first document found online was high level and general information about the sensor, but the manufacturer did provide another document that contained the information of the commands and responses to and from the lidar, and their packet structure. The documents did not clearly state the angles with respect to the lidar are fixed, which left me wondering if the lidar will think the direction it is facing when powered on will become the new “zeroth” angle.

*'''UART Buffer Overflow:''' When first interfacing with the sensor, the incoming bytes of the lidar were printed on to the terminal to make sure there was a response and to make sense of the information. Since the command we sent results in 5 bytes of data per measurement samples from the lidar and the lidar measured 2000 times per second, there are will be roughly 10k Bytes per second of data incoming that need to be handled continuously. With an improperly sized UART buffer and print statements it is guaranteed to occur, making the lidar data look like random values.

*'''Proper Parsing of Measurement Data:''' After sending a command to the lidar, the sensor will send a response packet, followed by the measurement data. The initial response from the lidar is a 7-byte packet, followed by continuous 5-byte measurement samples. I needed to make sure however I handled the response would be independent of how the measurement is handled, so as not to create a potential unwanted offset when receiving measurements.

*'''Object Detection with Received Data:''' Once proper communication was set up with the lidar and measurement data was getting decoded, there needed to be a way to measure when obstacles were present. If ~360 measurements are handled entirely independently from one another, it could become a complex and confusing code. To achieve a simple approach, four sectors about 20 degrees in size were used to represent the front, left, right, and rear directions.

*'''Bugs in Code:''' When first implementing the code, there were a few bugs from typos, incorrect numbers, and some faulty logic that were found with the use of unit testing. Unit testing helped find these issues and verified the logic was correct, and I would say gave me 90% confidence in my lidar handling.

<HR>
 

== '''Bridge [Bridge and Sensor Controller]'''==
<Picture and link to Gitlab>

Bridge functionality of the Bridge and Sensor Controller is to establish wireless communication between the SJ-2 Board and the android mobile device using the HC-05 Bluetooth module. The Bridge controller will be receiving start command with destination GEO coordinates and stop command. The Bridge controller will be transmitting the required sensor data and debug information to be displayed on the android application.

[[File:CMPE243_S20_T2_BRIDGE.png|thumb|center|500px| Bridge Diagram]]

===Bluetooth===

==== Software Design ====
<ol>
<li> Low-Level Layer
In this layer, similar to the GPS the UART GPIO was initialized (RX, TX), FreeRTOS Queue was initialized for UART Interrupts and the line buffer module was initialized to parse strings.

Two basic functions '''bt__read''' and '''bt__write''' were implemented.
As the name suggested, '''bt__write''' took a string as its input parameter and transmitted that data to the Android application. '''bt__read''' stored the incoming characters into the line buffer, parsed the line received into its identifier and tokens, and invoked a callback function.

Since this was a low-level layer the User would not be directly invoking this library. Instead a '''Bluetooth Wrapper''' module was created which would be invoked and used by the user.
</li>

<li>Application Layer

The Bluetooth Wrapper module had the appropriate '''read_once''' and '''write_once''' functions.

The `read_once` function internally just called the '''bt__read''' function. All of the decodings was done inside the Callback Function.
To get the Destination coordinate the string received from the Android Application was in the form of
<pre>$loc,<destination_latitude>,<destination_longitude>.</pre>
Upon receiving this data we parsed the destination_latitude and destination_longitude, which could later be accessed using getters.
We also set a start flag to notify the Driver Node that destination has been received and we can start steering towards our checkpoints.
Another command implemented was the stop command.
<pre>$stop</pre>
This was used to send a stop flag to the Driver node.

The '''write_once''' function used the getter methods from each CAN Decode message and update its internal state variables. A CSV String was created using the <pre>$canster</pre> identifier and various debugging points were appended to this message using a comma.
On the Android application side this CSV string was tokenized and displayed onto the Application Debug screen appropriately.
</li>
</ol>

==== Technical Challenges ====

<List of problems and their detailed resolutions>

<HR>
 

== '''Driver [Driver and LCD Controller]''' ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===

[[File:CMPE243_S20_T2_Canster Truck_Driver_Flowchart.png|thumb|center|750px|Driver Flowchart]]

The above block diagram explains the process flow of obstacle detection for the car. The LIDAR detects
the obstacle and depending on the distance of obstacle the car takes a slight right and slight left or a
hard right and hard left. The state of the car also depends on the value of the LIDAR and ultrasonic sensor.
The loose ends of the LIDAR for the reverse condition are checked by the ultrasonic sensors. The
The ultrasonic sensor works on the principle of trigger and echo and can detect the obstacles very close by.
The range of the Ultrasonic sensor is lower than the LIDAR. Finally, if no obstacle is detected the car goes
straight until the destination is reached. The speed of the car is also various when an obstacle is detected to
avoid the crash and the car’s smooth transition from one state to another. The key to the android
application controls the start and stop the process of the car. If the key is not pressed, then the stays in the

neutral state. The speed of the car is controlled by the changing duty cycle of the input voltage. There
are seven-speed levels in which the motor can run on. These speed levels are Forward Slow, Medium,
Fast, Reverse Slow, Medium, Fast, and Neutral. The Neutral is the stop condition with a 0% duty cycle.

=== Technical Challenges ===

< List of problems and their detailed resolutions>

<HR>
 

== '''LCD [Driver and LCD Controller]''' ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
The GLCD used was created by 4DSystems, using their IDE a UI was created. Each UI component could be controlled by sending UART data targeted at the widget address.
The best part about this GLCD was that we had a lot of interactive widgets to display debugging information in real-time.
The GLCD code was divided into 3 parts:
<ol>
<li>'''Low-Level Initialization'''
Initialize the low-level hardware interfaces to send and receive data from the GLCD.
Similar to the GPS and Bluetooth, The UART GPIO was initialized (RX, TX), FreeRTOS Queue was initialized for UART Interrupt and line buffer was used to get a stream of data for parsing.

Low-level '''read''' and '''write''' commands were used as per the working of the GLCD Module.
When Reading data pertaining to a widget on the GLCD we would need to send a particular response packet.
<pre>
void lcd__read(lcd_object_e object_id, uint8_t object_index, uint8_t *response, uint16_t *response_data) {

uint8_t checksum = READ_OBJ ^ object_id ^ object_index;
uint8_t buffer[] = {READ_OBJ, object_id, object_index, checksum};

lcd__write_data(buffer, sizeof(buffer) / sizeof(uint8_t));
lcd__read_response_id(response);
lcd__read_response_data(response_data);
}
</pre>

The response_data returned contains the Widget ID as well as the current value stored on that widget.

When Writing data pertaining to a widget on a GLCD the process is similar to the above mentioned code.
<pre>
void lcd__write(lcd_object_e object_id, uint8_t object_index, uint8_t msb, uint8_t lsb, uint8_t *response) {
uint8_t checksum = WRITE_OBJ ^ object_id ^ object_index ^ msb ^ lsb;
uint8_t buffer[] = {WRITE_OBJ, object_id, object_index, msb, lsb, checksum};

lcd__write_data(buffer, sizeof(buffer) / sizeof(uint8_t));
lcd__read_response_id(response);
}
</pre>

However in this case we receive only an ACK or NACK from the system. ACK would mean that the write to GLCD widget was successful and the widget now stored appropriate values. NACK would mean that a particular error has occurred. The errors could be regarding baud rate, incorrect bit format, incorrect index values, etc.
</li>
<li>'''GLCD Wrapper for Widgets'''
The above low-level code had generic read and write functions. However for our UI we were only using 3 Widgets. All of which had '''different Indexes''' and '''Widget IDs'''.
Therefore a very simple library was created to easily interface with those widgets
<pre>
bool lcd_wrapper__read_led(uint8_t index);
uint16_t lcd_wrapper__read_meter(uint8_t index);
uint16_t lcd_wrapper__read_leddigit(uint8_t index);

bool lcd_wrapper__write_led(uint8_t index, bool value);
bool lcd_wrapper__write_meter(uint8_t index, uint16_t value);
bool lcd_wrapper__write_leddigit(uint8_t index, uint16_t value);
</pre>

The above code is self-explanatory read and write functions for '''LED''', '''METER''', and '''LED DIGIT'''.
</li>
<li>'''GLCD UI'''
Now that we had our low level and Widget wrapper working properly, we wanted to create our Dynamic UI as well. The code would need to be robust enough to handle any UI that we create on the GLCD which could be reflected equivalently in our C Code.

<pre>
static void lcd_ui__update_ui(void) {

lcd_wrapper__write_led(LCD_LED_DRIVER_MIA_INDEX, driver_mia_led);
lcd_wrapper__write_led(LCD_LED_SENSOR_MIA_INDEX, sensor_mia_led);
lcd_wrapper__write_led(LCD_LED_GEO_MIA_INDEX, geo_mia_led);
lcd_wrapper__write_led(LCD_LED_MOTOR_MIA_INDEX, motor_mia_led);

// kph is always in the range of 0 - 10
lcd_wrapper__write_meter(LCD_METER_KPH_INDEX, kph_meter % 11);

// These will be in the Range of 0-99
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_RPM_INDEX, rpm_leddigit % 100);
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_CURRENTDEGREE_INDEX, cdegree_leddigit % 100);
lcd_wrapper__write_leddigit(LCD_LEDDIGIT_REQUIREDDEGREE_INDEX, rdegree_leddigit % 100);
}
</pre>

As we can see the `lcd_ui__update_ui` function was called periodically inside the 1Hz function. It updated the screen in real time based on the static values that were stored AND updated inside the LCD UI module.
The Constant INDEX values stored were directly mapped onto the Index values were received from the 4DWorkshop UI Software.
</li>
</ol>

=== Technical Challenges ===

< List of problems and their detailed resolutions>

<HR>
 

== '''Android Application''' ==
[https://gitlab.com/akhilcherukuri/can-ster_truck_application Gitlab]
=== Software Design ===

<div><ul>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android1.jpg|thumb|none|250px|Splash Screen]]</li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android2.jpg|thumb|none|250px|Main Activity Screen]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android3.jpg|thumb|none|250px|Map Activity Screen]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android4.jpg|thumb|none|250px|Info Activity Screen 1]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android5.jpg|thumb|none|250px|Info Activity Screen 1]] </li>
<li style="display: inline-block;">[[File:CMPE243_S20_T2_Canster Truck_Android6.jpg |thumb|none|250px|Debug Activity Screen]]</li>
</ul></div>

The application consists of a total of 5 Activities:

*'''Main Activity:'''
**This is the app launch display screen
**It will check for all the required permission onStart().
**Has search button for connecting from a paired device list view
**Once device is clicked, an intent will start the Map Activity
*'''Map Activity:'''
** For this requirement we are using the Google Maps Fragment, for the map fragment to function we must request an API key from Google and set the key in the manifest of the application.
** Destination marker(Red Marker) is set using setOnMapClickListener to which the car will navigate to, the destination can be changed by clicking elsewhere on the Map Fragment. The marker can be removed using setOnMarkerClickListener.
** When the start button is pressed, the start command identifier along with destination latitude and longitude is sent to the car via the write thread. A background thread is started along with it to indicate the current car's position(Green Marker) along with a plotline between the current position and destination.
** When the stop button is pressed, the stop command identifier is sent to the car, to stop and turn off the car.
*'''Info Activity:'''
** Messages from Geological, Driver, Motor coming from CAN bus are decoded by the Sensor and Bridge controller and sent to the Android application as a string.
** The received string is parsed and categorizes the data to store it in the required textView to be displayed.
** Bluetooth status, Lidar Values, Ultrasonic Sensor Values, Motor Speed, Motor RPM, Motor PWM, Cars' current location, Compass Heading, Distance till Destination, Checkpoint Index is displayed. This was useful for debugging purposes and allowed us to avoid scanning the mounted LCD or CAN Busmaster on PC during drives.
*'''Debug Activity:'''
**The main function of this activity is to check all RAW RX and RAW TX messages and create a log of all the data received and sent.
*'''Bluetooth Connection Service Activity''' :
**This is the background activity that handles all the threads required for transmission and receiving data using Bluetooth connections. It has 3 running threads which is called inside other activities using a handler:
** Accept Thread - Listens to BluetoothServerSocket using listenUsingRfcommWithServiceRecord. In order for the RF communication socket to connect to the HC-05, we used the following UUID: 00001101-0000-1000-8000-00805F9B34FB. This is a generic SSP Bluetooth UUID that enables the socket to directly connected to HC-05 and maintain the connection.
** Connect Thread - Creates a Bluetooth socket using createRfcommSocketToServiceRecord
** Connected Thread - Creates socket.getInputStream(); and socket.getOutputStream(); when bytes are available in input stream it will read them into a buffer.
***All messages for activities are done by Handler mHandler.obtainMessage(); mHandler.sendMessage();

*'''Receieved string''':
** A String is sent to the Bluetooth app from HC-05 and when it receives a string with identifier "$canster", the message is prased accordingly by using the string delimiter ',' and is ended by the newline character '\n' which will remove the data from StringBuffer.
** Example: $canster,37.339334,-121.881123,37.338713,-121.880685,10.123,20.133,30.123,10.5,88.1,99.2,-2,1,44,7,11,22,33,-3,23\n

[[File:CMPE243_S20_T2_BLUETOOTHFLOWCHART.png|thumb|center|650px| Android Application Flowchart]]

=== Technical Challenges ===

<HR>
 

== '''Mangaement''' ==
===Team Management ===
===Git Management===

Git Management amongst 6 team members was definitely a very challenging task. Depending on our initial design we could’ve had a lot of merge conflicts. However those risks were mitigated by spending a LOT of time in the initial stages to decide our pipeline and structure.

<li>There are certain components in our system that were COMMON. For example the CAN initialization, communication and decodes were all similar for the most part between all the 4 Controllers. The utility modules used were also similar in nature</li>
<li>Thus we made a common branch that contained the templates for CAN Nodes (not Controllers), Hardware code and Utility functions.
<ol>
<li>Later this common branch was forked into an individual Controller specific branch (SENSOR, GEO, MOTOR or DRIVER).</li>
<li>Only the Logic folder contained Controller specific code, specific to that controller.</li>
</ol>
<li>This gave us a lot of flexibility since all the team members had similar APIs to work with on all 4 branches. This promoted easy understanding and learning.
<ol>
<li>Many team members frequently worked on 2 or more controllers at a time where can messages were concerned. Having a APIs also meant that just the can_handler needed to be updated regularly followed by the equivalent logic code. </li>
<li>Inside the logic folder, getters to the can node modules were frequently used.</li></ol>
<pre>
├───can_module
│ ├───can_bus_initializer
│ ├───can_constants
│ ├───can_driver_node
│ ├───can_geo_node
│ ├───can_handler
│ ├───can_motor_node
│ ├───can_sensor_node
│ └───test
├───hardware
│ ├───bt
│ ├───compass
│ ├───gps
│ ├───lcd
│ ├───test
│ └───ultrasonic
├───logic
│ ├───driver_obstacle
│ ├───driver_state
│ ├───geo_logic
│ └───test
├───periodics
│ └───test
└───utility
├───line_buffer
└───test
</pre>

'''Challenges'''
<li>It was initially a bit of a learning curve to understand the flow of the repository</li>
<li>When using a git management system with different versions in each branch it became very tough when the number of branches suddenly exploded in size. A lot of relevant code was stuck in a lot of different branches.
<ol>
<li>This happened mainly due to assignment submissions and unclosed MRs that eventually became stale.</li>
<li>Our strategy was to abandon these MRs and keep forking from these branches without merging it back into its final controller branch.</li>
<li>The latest branches that were kept were aptly named `<controller>_bleeding_edge_dev` branches since they were never merged back from where they were forked.</li>
</ol>
<li>Since a lot of our code also depended on the DBC autogenerated code, we could not suddenly change the DBC Message names once they were established since it caused a change in the Struct name that was generated and used.
<ol>
<li>Our solution to this was to keep everything backward compatible. We added new function names without deleting old DBC messages.</li>
<li>In certain places where we wanted to modify a function name it was done one by one so that a lot of the code is not broken at one time.</li>
</ol>
<li>Common Branches eventually became stale as our progress continued on the bleeding edge branches
<ol>
<li>For example certain GPS features needed to be added which were done on the GEO_bleeding_edge_dev branch but never pushed or cherry-picked back into the COMMON branch.</li>
<li>This was a similar issue to our 2nd point but manageable since the goal of the COMMON branch was to provide a template for further work and nothing more.</li>
<li>At the end of the day each controller is its own Individual Project and while the messages between them are same. The Hardware code does not need to be same.</li>
<li>This also prompted team-members to ask if we could delete unused hardware or logic file code (which wasn’t being used and was imported from the template). This was also fine and can be done during cleanup stage. However we eventually got used to the Modular system of our project so much so that we did not worry about the additional modules that were present in each branched controller project.</li>
</ol>

<HR>
 

== '''Conclusion''' ==
CMPE243 gives one of the best experiences one could ever get in their academic life. The course is designed to give an insight into how the industry functions and enhances both technical and management skills. Apart from learning how to work and implement application of CAN protocol, one can get a hands-on experience with version control, unit-testing and software design. Overall it was a very great journey.

=== Project Video ===

=== Project Source Code ===

=== Advise for Future Students ===
'''GENERAL:'''
* Form your team and start the project as early as you can.
* Clearly discuss what role each individual should do and ensure that progress is regularly tracked so that the team doesn't fall back on any schedule.
* Since lot of code and hardware integration is involved with this project, make sure testing is thoroughly and periodically done and make note of all the issues found.
'''HARDWARE:'''
* Decide on how you would power up the peripherals. We had issues with Bluetooth (not connecting), GPS (lock not happening) and LIDAR (giving incorrect values). After lot of cycles of hardware and software debugging, we found that the issue was with power. Choose wisely as to which peripherals must be connected to which power bank.
* PCB design is time consuming as there is a lot of hardware components involved and a huge responsibility falls on the designer to know the about each component. Coordinating with multiple team members and verifying with them if their respective hardware is correct takes a lot of time. So start well ahead.
* Make sure to expose some extra GPIO and GND pins for future use.
'''MOTOR:'''
*You can use the LiPo battery to power the RPM and servo motor instead of using a separate power source. Use Vout from the ESC to get 6V.
*Start the PID control calibration early on as you will need to do extensive testing to get it working.

=== Acknowledgement ===
<HR>
Firstly we would like to express our gratitude to Professor Preetpal Kang for his guidance throughout the semester and providing us with this opportunity. We would also like to thank the ISA members Vignesh Kumar Venkateshwar and Aakash Vrajlal Chitroda for being available whenever in need and guiding us to complete the project.

== '''References''' ==

===Motor Controller===
===Geological Controller===
* Movable Scripts: [https://www.movable-type.co.uk/scripts/latlong.html Calculate distance, bearing and more between Latitude/Longitude points]
* CMPS11:[https://www.robot-electronics.co.uk/htm/cmps11i2c.htm I2C Configuration]

===Bridge and Sensor Controller===
===Driver and LCD Controller===
*LCD Software: [https://4dsystems.com.au/ulcd-32ptu 4Dsystems]
===Android===
*Youtube Channel: [https://www.youtube.com/channel/UCoNZZLhPuuRteu02rh7bzsw Coding with Mitch]
*Android Developers: [https://developer.android.com/guide/topics/connectivity/bluetooth Website][https://github.com/googlearchive/android-BluetoothChat Github]
*Udemy Course: [https://www.udemy.com/course/the-complete-android-oreo-developer-course/ Complete Android Oreo Developer Course]
===PCB Design===
*EDC Tool: [https://easyeda.com/ EasyEDA]

Industrial Application using CAN Bus

2020-03-11T01:24:51Z

Proj user22: /* Spring 2020 */

= Class Information =
==Presentation on Autonomous Vehicles==
http://www.slideshare.net/ShantanuVashishtha1/autonomous-vehicles-70049669

== Useful Topics ==

=== Git ===
[[Basic Git Tutorial]]
 

=== CAN Bus ===
[[CAN BUS Tutorial | CAN BUS]]
 

=== [[DBC Format]] ===
DBC format is a well known format to describe the format of a CAN message. This is essentially the schema of the data that is communicated over the CAN bus. Please view the linked [[DBC Format]] article for details before reading further.

=== BusMaster Tutorial ===
[[BusMaster | BusMaster Tutorial]]

== Class Assignments ==
=== [[Lab Assignments]] ===

 
== Class Project ==
=== [[Self-driving Car]] ===
In this class project, students accomplish a self-drivable RC car with the following learning objectives:
* Learn CAN Bus and how to communicate in an industrial or automotive environment.
* Learn integration and testing across different controllers.
* Learn how to work in teams.
* Learn basics of an RTOS.
 

[[Autonomous RC Car Project Report Template]]

== Class Project Reports ==

=== [[Spring 2020 | Spring 2020]] ===
* [[S20: Nimble]]
* [[S20: Bucephalus]]
* [[S20: Canster Truck]]
* [[S20: Tesla Model RC]]

=== [[Spring 2019 | Spring 2019]] ===
* [[S19: CANT Bus | S19: CANT Bus]]
* [[S19: Tech Savy | S19: Tech Savy]]
* [[S19: Mystery Machine | S19: Mystery Machine]]
* [[S19: Run D.B.C | S19: Run D.B.C]]
* [[S19: Hot Wheels | S19: Hot Wheels]]
* [[S19: Zeus | S19: Zeus]]
* [[S19: Automophiles | S19: Automophiles]]
* [[S19: Lightfury | S19: Lightfury]]

=== [[Fall 2017 | Fall 2017]] ===
* [[F17: Alpha | F17: Alpha]]
* [[F17: FoxP2 | F17 FoxP2]]
* [[F17: Optimus | F17 Optimus]]
* [[F17: Tata Nano | F17 Tata Nano]]
* [[F17: Viserion | F17 Viserion]]
* [[F17: Vindicators100 | F17 Vindicators100]]
* [[F17: Rolling Thunder | F17: Rolling Thunder]]

=== [[Fall 2016 | Fall 2016]] ===
* [[F16: Spartan and Furious | F16: Spartan and Furious]]
* [[F16: Titans | F16: Titans]]
* [[F16: Kasper | F16: Kasper]]
* [[F16: AutoNav | F16: AutoNav]]
* [[F16: Thunderbolt| F16: Thunderbolt]]
* [[F16: The-Nine| F16: The-Nine]]

=== [[Fall 2015 | Fall 2015]] ===
* [[F15: Quadcopter by Thomas]]
* [[F15: Undergrads++]]
* [[F15: TopGun]]
* [[F15: Fury]]
* [[F15: Minion]]
* [[F15: ThunderBird]]

=== [[CmpE243 Fall 2014 | Fall 2014]] ===

* [[F14: Team2-Self Driving Car - AUG]]
* [[F14: Team3-Self Driving Car - Optimus Prime]]
* [[F14: Team4-Self Driving Car - AUG]]
* [[F14: Team5-Self Driving Car - AUG]]
* [[F14: Self Driving Undergrad Team]]

S20: CAN-ster Truck

2020-03-11T01:04:22Z

Proj user22: Created page with "CAN-STER TRUCK LOGO == CAN-STER TRUCK == == Abstract == The CAN-STER Truck Project is an autonomous RC car with CAN Bus i..."

[[File:group_logo.jpg|thumb|795px|caption|right|CAN-STER TRUCK LOGO]]

== CAN-STER TRUCK ==

== Abstract ==
The CAN-STER Truck Project is an autonomous RC car with CAN Bus interfaced controllers. The development of the RC car's subsystem modules (Interfacing of Ultrasonic Sensor, LIDAR, Bluetooth, GPS and CAN modules) was divided among by six team members. The aim of the project is to develop an autonomous RC Car which can navigate from the source location to a selected destination by avoiding obstacles in its path using sensors and motors.

=== Introduction ===

The project was divided into N modules:

* Sensor ...
* Motor..
* ...
* Android

=== Team Members & Responsibilities ===
<Team Picture>

Gitlab Project Link - [https://gitlab.com/coder137/can-ster_truck Gitlab]
 

<Provide ECU names and members responsible>
<One member may participate in more than one ECU>
 
'''Team Roles are Pending'''
 
1) Niket Naidu [https://gitlab.com/coder137 Gitlab]
 
2) Ashish Anant Ladage [https://gitlab.com/ashishladage1 Gitlab]
 
3) Ganesh Ram Pamadi [https://gitlab.com/ganeshram2493 Gitlab]
 
4) Nikhil Pabbisetty [https://gitlab.com/nikhilpeoria Gitlab]
 
5) Akhil Cherukuri [https://gitlab.com/akhilcherukuri Gitlab]
 
6) Jesus De Haro De Reza [https://gitlab.com/deharo27 Gitlab]
 

* Sensor
** Link to Gitlab user1
** Link to Gitlab user2

* Motor
** Link to Gitlab user1
** Link to Gitlab user2

* Geographical
** Link to Gitlab user1
** Link to Gitlab user2

* Communication Bridge Controller & LCD
** Link to Gitlab user1
** Link to Gitlab user2

* Android Application
** Link to Gitlab user1
** Link to Gitlab user2

* Testing Team
** Link to Gitlab user1
** Link to Gitlab user2

<HR>
 

== Schedule ==

{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-

! scope="row"| 1
| 02/11/2020
| 02/17/2020
|
*Form teams and decide group name
*Review past projects
*Create Slack group and invite Preet
*Create groups Gitlab repository
*Analysis of component required

|
*Completed
*Completed
*Completed
*Completed
*Completed
|-

! scope="row"| 2
| 02/18/2020
| 02/24/2020
|
*Study CAN Communication
*Create Bill of Materials
*Order RC Car
|
*Completed
*Completed
*Completed
|-

! scope="row"| 3
| 02/25/2020
| 03/02/2020
|
*Setup team finance management using Splitwise
*Complete Bill of Materials
*Order all other required components
|
*Completed
*Completed
*Completed
|-

! scope="row"| 4
| 03/03/2020
| 03/09/2020
|
*Read the respective datasheets and manuals for each component
*Test each component for working conditions
|
*Completed
*Completed
|-

! scope="row"| 5
| 03/10/2020
| 03/16/2020
|
*Assign team responsibilities and roles
*Environmental setup of Android
*Decide PCB Editing Software (Kicad vs Eagle)
|
*Pending
|-

! scope="row"| 6
| 03/17/2020
| 03/23/2020
|
*Incomplete

|
*Pending
|-

! scope="row"| 7
| 03/24/2020
| 03/30/2020
|
*Incomplete

|
*Pending
|-

! scope="row"| 8
| 03/31/2020
| 04/06/2020
|
*Incomplete

|
*Pending
|-

! scope="row"| 9
| 04/07/2020
| 04/13/2020
|
*Incomplete

|
*Pending
|-

! scope="row"| 10
| 04/14/2020
| 04/20/2020
|
*Incomplete

|
*Pending
|-

! scope="row"| 11
| 04/21/2020
| 04/27/2020
|
*Finalize RC Car For Project Proto 1

|
*Pending
|-

! scope="row"| 12
| 04/28/2020
| 05/04/2020
|
*April 28th: Project Proto 1
*Finalize RC Car for Project Demo
*May 1st: Project Presentation
*Finalize RC Car for Project Proto 2
|
*Pending
*Pending
|-

! scope="row"| 13
| 05/14/2020
| 05/21/2020
|
* Complete Individual Contribution Peer Grading
* Review and Complete Wiki Project Page
|
*Pending
*Pending
|-
|}

<HR>
 

== Bill Of Materials ==
{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Part Model & Vendor
! scope="col"| Quantity
! scope="col"| Cost in USD
|-
! scope="row"| 1
| Microcontroller Boards
| SJ2 LPC 1758 (Purchased from Preet Kang)
| 5
| $250.00
|-
! scope="row"| 2
| CAN Transceivers
| [http://www.microchip.com/wwwproducts/en/en010405 Microchip MCP2551-I/P]
| 15
| Free Samples
|-
! scope="row"| 3
| RC Car
| [https://www.amazon.com/Traxxas-Slash-Course-2-4GHZ-Vehicle/dp/B01DU474B0/ref=sr_1_3?ie=UTF8&qid=1474747759&sr=8-3&keywords=Traxxas+1%2F10+slash+2wd Traxxas 2WD RTR with 2.4Ghz Radio]
| 1
| $260.00
|-
! scope="row"| 4
| Lithium-Ion Battery
| [https://www.rcsuperstore.com/traxxas-7600mah-2s-7-4v-25c-id-lipo-battery-pack/ Traxxas 7600mAh 2S 7.4V 25C iD LiPo Battery Pack]
| 1
| $75.00
|-
! scope="row"| 5
| Lithium-Ion Battery Charger
| [https://www.amazon.com/Traxxas-2970-EZ-Peak-Charger-Identification/dp/B00OAFYLJC/ref=pd_bxgy_21_img_2?ie=UTF8&psc=1&refRID=JVX791WVV9Y8T9DW92KW Traxxas 2970 EZ-Peak Plus 4-Amp NiMH/LiPo Fast Charger]
| 1
| $50.00
|-
! scope="row"| 6
| Compass CMP11
| [https://www.dfrobot.com/product-1275.html DFRobot CMPS11 Compass]
| 1
| $29.99
|-
! scope="row"| 7
|
|
| 1
| $
|-
! scope="row"| 8
|
|
| 1
| $
|-
! scope="row"| 9
|
|
| 1
| $
|-
! scope="row"| 10
|
|
| 1
| $
|-
|}

<HR>
 

== Printed Circuit Board ==
<Picture and information, including links to your PCB>
 

<HR>
 
== CAN Communication ==
<Talk about your message IDs or communication strategy, such as periodic transmission, MIA management etc.>

=== Hardware Design ===
<Show your CAN bus hardware design>

=== DBC File ===
<Gitlab link to your DBC file>
<You can optionally use an inline image>

<HR>
 
== Sensor ECU ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
<List the code modules that are being called periodically.>

=== Technical Challenges ===

< List of problems and their detailed resolutions>

<HR>
 
== Motor ECU ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
<List the code modules that are being called periodically.>

=== Technical Challenges ===

< List of problems and their detailed resolutions>

<HR>
 
== Geographical Controller ==

<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
<List the code modules that are being called periodically.>

=== Technical Challenges ===

< List of problems and their detailed resolutions>

<HR>
 

<HR>
 
== Communication Bridge Controller & LCD ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
<List the code modules that are being called periodically.>

=== Technical Challenges ===

< List of problems and their detailed resolutions>

<HR>
 
== Master Module ==

<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
<List the code modules that are being called periodically.>

=== Technical Challenges ===

< List of problems and their detailed resolutions>

<HR>
 
== Mobile Application ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
<List the code modules that are being called periodically.>

=== Technical Challenges ===

< List of problems and their detailed resolutions>

 
<HR>
<HR>
 
== Conclusion ==
<Organized summary of the project>

<What did you learn?>

=== Project Video ===

=== Project Source Code ===

=== Advise for Future Students ===
<Bullet points and discussion>

=== Acknowledgement ===

=== References ===

Industrial Application using CAN Bus

2020-03-11T01:01:09Z

Proj user22: /* Spring 2020 */

= Class Information =
==Presentation on Autonomous Vehicles==
http://www.slideshare.net/ShantanuVashishtha1/autonomous-vehicles-70049669

== Useful Topics ==

=== Git ===
[[Basic Git Tutorial]]
 

=== CAN Bus ===
[[CAN BUS Tutorial | CAN BUS]]
 

=== [[DBC Format]] ===
DBC format is a well known format to describe the format of a CAN message. This is essentially the schema of the data that is communicated over the CAN bus. Please view the linked [[DBC Format]] article for details before reading further.

=== BusMaster Tutorial ===
[[BusMaster | BusMaster Tutorial]]

== Class Assignments ==
=== [[Lab Assignments]] ===

 
== Class Project ==
=== [[Self-driving Car]] ===
In this class project, students accomplish a self-drivable RC car with the following learning objectives:
* Learn CAN Bus and how to communicate in an industrial or automotive environment.
* Learn integration and testing across different controllers.
* Learn how to work in teams.
* Learn basics of an RTOS.
 

[[Autonomous RC Car Project Report Template]]

== Class Project Reports ==

=== [[Spring 2020 | Spring 2020]] ===
* [[S20: Nimble]]
* [[S20: Bucephalus]]
* [[S20: CAN-ster Truck]]
* [[S20: Tesla Model RC]]

=== [[Spring 2019 | Spring 2019]] ===
* [[S19: CANT Bus | S19: CANT Bus]]
* [[S19: Tech Savy | S19: Tech Savy]]
* [[S19: Mystery Machine | S19: Mystery Machine]]
* [[S19: Run D.B.C | S19: Run D.B.C]]
* [[S19: Hot Wheels | S19: Hot Wheels]]
* [[S19: Zeus | S19: Zeus]]
* [[S19: Automophiles | S19: Automophiles]]
* [[S19: Lightfury | S19: Lightfury]]

=== [[Fall 2017 | Fall 2017]] ===
* [[F17: Alpha | F17: Alpha]]
* [[F17: FoxP2 | F17 FoxP2]]
* [[F17: Optimus | F17 Optimus]]
* [[F17: Tata Nano | F17 Tata Nano]]
* [[F17: Viserion | F17 Viserion]]
* [[F17: Vindicators100 | F17 Vindicators100]]
* [[F17: Rolling Thunder | F17: Rolling Thunder]]

=== [[Fall 2016 | Fall 2016]] ===
* [[F16: Spartan and Furious | F16: Spartan and Furious]]
* [[F16: Titans | F16: Titans]]
* [[F16: Kasper | F16: Kasper]]
* [[F16: AutoNav | F16: AutoNav]]
* [[F16: Thunderbolt| F16: Thunderbolt]]
* [[F16: The-Nine| F16: The-Nine]]

=== [[Fall 2015 | Fall 2015]] ===
* [[F15: Quadcopter by Thomas]]
* [[F15: Undergrads++]]
* [[F15: TopGun]]
* [[F15: Fury]]
* [[F15: Minion]]
* [[F15: ThunderBird]]

=== [[CmpE243 Fall 2014 | Fall 2014]] ===

* [[F14: Team2-Self Driving Car - AUG]]
* [[F14: Team3-Self Driving Car - Optimus Prime]]
* [[F14: Team4-Self Driving Car - AUG]]
* [[F14: Team5-Self Driving Car - AUG]]
* [[F14: Self Driving Undergrad Team]]

S20: Canster Truck

2020-03-11T00:53:25Z

Proj user22: /* Abstract */

S20: Canster Truck

2020-03-11T00:51:13Z

Proj user22:

[[File:group_logo.jpg|thumb|795px|caption|right|CAN-STER TRUCK LOGO]]

== CAN-STER TRUCK ==

== Abstract ==
The CAN-STER Truck Project is an autonomous RC car with CAN Bus interfaced controllers. The development of the R.C car's subsystem modules was divided amongst and performed by six team members. The aim of the project is to develop an autonomous RC Car which can navigate from the source location to a selected destination by avoiding obstacles in its path using sensors and motors.

=== Introduction ===

The project was divided into N modules:

* Sensor ...
* Motor..
* ...
* Android

=== Team Members & Responsibilities ===
<Team Picture>

Gitlab Project Link - [https://gitlab.com/coder137/can-ster_truck Gitlab]
 

<Provide ECU names and members responsible>
<One member may participate in more than one ECU>
 
'''Team Roles are Pending'''
 
1) Niket Naidu [https://gitlab.com/coder137 Gitlab]
 
2) Ashish Anant Ladage [https://gitlab.com/ashishladage1 Gitlab]
 
3) Ganesh Ram Pamadi [https://gitlab.com/ganeshram2493 Gitlab]
 
4) Nikhil Pabbisetty [https://gitlab.com/nikhilpeoria Gitlab]
 
5) Akhil Cherukuri [https://gitlab.com/akhilcherukuri Gitlab]
 
6) Jesus De Haro De Reza [https://gitlab.com/deharo27 Gitlab]
 

* Sensor
** Link to Gitlab user1
** Link to Gitlab user2

* Motor
** Link to Gitlab user1
** Link to Gitlab user2

* Geographical
** Link to Gitlab user1
** Link to Gitlab user2

* Communication Bridge Controller & LCD
** Link to Gitlab user1
** Link to Gitlab user2

* Android Application
** Link to Gitlab user1
** Link to Gitlab user2

* Testing Team
** Link to Gitlab user1
** Link to Gitlab user2

<HR>
 

== Schedule ==

{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Week#
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
|-

! scope="row"| 1
| 02/11/2020
| 02/17/2020
|
*Form teams and decide group name
*Review past projects
*Create Slack group and invite Preet
*Create groups Gitlab repository
*Analysis of component required

|
*Completed
*Completed
*Completed
*Completed
*Completed
|-

! scope="row"| 2
| 02/18/2020
| 02/24/2020
|
*Study CAN Communication
*Create Bill of Materials
*Order RC Car
|
*Completed
*Completed
*Completed
|-

! scope="row"| 3
| 02/25/2020
| 03/02/2020
|
*Setup team finance management using Splitwise
*Complete Bill of Materials
*Order all other required components
|
*Completed
*Completed
*Completed
|-

! scope="row"| 4
| 03/03/2020
| 03/09/2020
|
*Read the respective datasheets and manuals for each component
*Test each component for working conditions
|
*Completed
*Completed
|-

! scope="row"| 5
| 03/10/2020
| 03/16/2020
|
*Assign team responsibilities and roles
*Environmental setup of Android
*Decide PCB Editing Software
|
*Pending
|-

! scope="row"| 6
| 03/17/2020
| 03/23/2020
|
*Incomplete

|
*Pending
|-

! scope="row"| 7
| 03/24/2020
| 03/30/2020
|
*Incomplete

|
*Pending
|-

! scope="row"| 8
| 03/31/2020
| 04/06/2020
|
*Incomplete

|
*Pending
|-

! scope="row"| 9
| 04/07/2020
| 04/13/2020
|
*Incomplete

|
*Pending
|-

! scope="row"| 10
| 04/14/2020
| 04/20/2020
|
*Incomplete

|
*Pending
|-

! scope="row"| 11
| 04/21/2020
| 04/27/2020
|
*Finalize RC Car For Project Proto 1

|
*Pending
|-

! scope="row"| 12
| 04/28/2020
| 05/04/2020
|
*April 28th: Project Proto 1
*Finalize RC Car for Project Demo
*May 1st: Project Presentation
*Finalize RC Car for Project Proto 2
|
*Pending
*Pending
|-

! scope="row"| 13
| 05/14/2020
| 05/21/2020
|
* Complete Individual Contribution Peer Grading
* Review and Complete Wiki Project Page
|
*Pending
*Pending
|-
|}

<HR>
 

== Bill Of Materials ==
{| class="wikitable" style="width: 100%;"
|-
! scope="col"| Item#
! scope="col"| Part Desciption
! scope="col"| Part Model & Vendor
! scope="col"| Quantity
! scope="col"| Cost in USD
|-
! scope="row"| 1
| Microcontroller Boards
| SJ2 LPC 1758 (Purchased from Preet Kang)
| 5
| $250.00
|-
! scope="row"| 2
| CAN Transceivers
| [http://www.microchip.com/wwwproducts/en/en010405 Microchip MCP2551-I/P]
| 15
| Free Samples
|-
! scope="row"| 3
| RC Car
| [https://www.amazon.com/Traxxas-Slash-Course-2-4GHZ-Vehicle/dp/B01DU474B0/ref=sr_1_3?ie=UTF8&qid=1474747759&sr=8-3&keywords=Traxxas+1%2F10+slash+2wd Traxxas 2WD RTR with 2.4Ghz Radio]
| 1
| $260.00
|-
! scope="row"| 4
| Lithium-Ion Battery
| [https://www.rcsuperstore.com/traxxas-7600mah-2s-7-4v-25c-id-lipo-battery-pack/ Traxxas 7600mAh 2S 7.4V 25C iD LiPo Battery Pack]
| 1
| $75.00
|-
! scope="row"| 5
| Lithium-Ion Battery Charger
| [https://www.amazon.com/Traxxas-2970-EZ-Peak-Charger-Identification/dp/B00OAFYLJC/ref=pd_bxgy_21_img_2?ie=UTF8&psc=1&refRID=JVX791WVV9Y8T9DW92KW Traxxas 2970 EZ-Peak Plus 4-Amp NiMH/LiPo Fast Charger]
| 1
| $50.00
|-
! scope="row"| 6
| Compass CMP11
| [https://www.dfrobot.com/product-1275.html DFRobot CMPS11 Compass]
| 1
| $29.99
|-
! scope="row"| 7
|
|
| 1
| $
|-
! scope="row"| 8
|
|
| 1
| $
|-
! scope="row"| 9
|
|
| 1
| $
|-
! scope="row"| 10
|
|
| 1
| $
|-
|}

<HR>
 

== Printed Circuit Board ==
<Picture and information, including links to your PCB>
 

<HR>
 
== CAN Communication ==
<Talk about your message IDs or communication strategy, such as periodic transmission, MIA management etc.>

=== Hardware Design ===
<Show your CAN bus hardware design>

=== DBC File ===
<Gitlab link to your DBC file>
<You can optionally use an inline image>

<HR>
 
== Sensor ECU ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
<List the code modules that are being called periodically.>

=== Technical Challenges ===

< List of problems and their detailed resolutions>

<HR>
 
== Motor ECU ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
<List the code modules that are being called periodically.>

=== Technical Challenges ===

< List of problems and their detailed resolutions>

<HR>
 
== Geographical Controller ==

<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
<List the code modules that are being called periodically.>

=== Technical Challenges ===

< List of problems and their detailed resolutions>

<HR>
 

<HR>
 
== Communication Bridge Controller & LCD ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
<List the code modules that are being called periodically.>

=== Technical Challenges ===

< List of problems and their detailed resolutions>

<HR>
 
== Master Module ==

<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
<List the code modules that are being called periodically.>

=== Technical Challenges ===

< List of problems and their detailed resolutions>

<HR>
 
== Mobile Application ==
<Picture and link to Gitlab>

=== Hardware Design ===

=== Software Design ===
<List the code modules that are being called periodically.>

=== Technical Challenges ===

< List of problems and their detailed resolutions>

 
<HR>
<HR>
 
== Conclusion ==
<Organized summary of the project>

<What did you learn?>

=== Project Video ===

=== Project Source Code ===

=== Advise for Future Students ===
<Bullet points and discussion>

=== Acknowledgement ===

=== References ===

F19: Infinity Mirror

2019-12-19T00:03:04Z

Proj user22: /* Team Members & Technical Responsibilities */

== '''Abstract''' ==

The main theme of the project is to build an interactive embedded system consisting of two entertainment modes - Music and Gaming. On the music mode, the MP3 decoder module reads songs from an SD card on the MCU board and plays the music through a speaker. It deals with the convergence of various services such as playing a game with background music, control volume, switch and pause/play songs. While the song is being played, audio frequency spectrum bands based on music tune are displayed on the LED Matrix band visualization etc. On the game mode, a fruit smashing game called “Fruit Fury” is implemented where the user needs to orient the MCU board in a direction according to where the fruit appears on the LED matrix. Alongside, the user can listen and switch songs. To achieve the above functionalities, various elements such as Audio Decoder, Audio frequency analyzer, 32x64 RGB LED Matrix and HC-05 bluetooth module and Android application are integrated.

[[File:High_level1.png|800px|thumb|center|Block Diagram of Infinity Mirror]]

== '''Introduction & Objectives''' ==

The key features supported by the system is real-time orientation recognition & trigger respective actions in 2 modes - MP3 mode and Game mode.

MP3 MODE:

1. Determine the accelerometer sensor values based on the orientation of the board and perform music control such as play, pause, volume control and changing songs.

2. In response, retrieve the data from the SD Card & communicate to the audio decoder for appropriate audio streaming.

3. Also implemented interaction with HC-05 bluetooth module through a customized mobile application and provide same operations.

4. Display frequency spectrum bands in sync to the tune of the song played.

[[File:frequency_bands.png|800px|thumb|center|Frequency bands]]

GAME MODE - Fruit Fury:

1. Determine the accelerometer sensor values based on the orientation of the board and hit the fruit in corresponding direction.

2. Incorporating provision on the board's switches to change to next or previous song.

3. Also implemented interaction with HC-05 bluetooth module through a customized mobile application and play the game through the same.

[[File:Title Screen.jpeg|800px|thumb|center|Title Screen]]

'''Project Objectives'''
'''1. Audio Decoder''' - Fetches song data from the SD card and plays it over a speaker.
'''2. RGB LED Matrix''' - Display frequency bands on music mode or view the game on game mode.
'''3. Audio Frequency Analyzer''' - To convert the audio data into 7 spectrum bands which is then displayed as individual colored bands on the LED matrix.
'''4. Bluetooth HC-05''' - Interfaces the system using Bluetooth to an Android application.

'''Team Objectives'''
'''1.''' Learn each and every module as much as possible, in order to develop an overall product.
'''2.''' Understand the proper use of queues and semaphores in order to send/receive the data between multiple tasks.
'''3.''' Learn to integrate all modules and ensuring smooth transition, communication and context switching at desired time intervals.
'''4.''' Document and track all the bugs encountered during development and learn to update git repository after every fix.

== '''Team Members & Technical Responsibilities''' ==
[[File:cmpe244_F19_Infinity_Mirror_members.jpeg|thumb|500x500px|TEAM INFINITY MIRROR|right]]

*'''''[http://linkedin.com/in/aakash-chitroda-17841740 Aakash Chitroda]'''''
** MP3 Audio Encoder/Decoder
** Audio frequency Analyzer logic
** Integrating MP3 player with the Game
** Monitoring and controlling the CPU utilization

*'''''[https://www.linkedin.com/in/ganeshram93 Ganesh Ram]'''''
** Interfacing of LED Matrix and driver design
** Game logic design
** Audio frequency spectrum logic on LED
** Packaging

*'''''[https://www.linkedin.com/in/niket-naidu-30090a134/ Niket Naidu]'''''
** Android & Bluetooth Application
** OLED Interfacing and Designing
** PCB Design improvements
** Accelerometer Sensor integration with OLED Screen

*'''''[https://www.linkedin.com/in/vidushi-jain-048b992a Vidushi Jain]'''''
** Bluetooth Communication
** Interfacing of Gesture & Accelerometer Sensors
** Hardware Designing & PCB Integration

 

== '''Administrative Responsibilities''' ==
{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|- style="vertical-align: top;"
! colspan="5" style="background:#588ecc" | Administrative Roles 
|-
! style="text-align: left;" |
* Team Lead 
| Aakash Chitroda 
|-
! style="text-align: left;" |
* Finance Manager
| Niket Naidu 
|-
! style="text-align: left;" |
* Git Repository Manager 
| Vidushi Jain 
|-
! style="text-align: left;" |
* Wiki Report Manager 
| Vidushi Jain 
 Ganesh Ram 
|-
! style="text-align: left;" |
* Bill of Materials Manager 
| Ganesh Ram 
|}

== '''Team Deliverables Schedule''' ==

{| class="wikitable"
|-
! scope="col" style="text-align: left;" style="background:#588ecc;" | WEEK
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
START DATE 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
END DATE 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
TASK DETAILS 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
STATUS 
|-
| 1 || 15 Oct 2019 || 22 Oct 2019 ||
*Create and establish GitLab repository
*Establish slack channel and invite Preet
*Look through previous years projects and study it
*Distribute major roles among team members
|| Completed Completed Completed Completed 
|-
| 2 || 23 Oct 2019 || 29 Oct 2019 ||
* Create a Bill of Materials 
* Select and order Parts 
* Review Data-sheet and Interfacing Of LED Matrix(Ganesh) 
* Review Data-sheet for Gesture sensor(Vidushi) 
* Make Repo on Gitlab for all modules - Follow Naming Convention. 
|| Completed Completed Completed Completed Completed 
|-
| 3 || 30 Oct 2019 || 5 Nov 2019 ||
* Review Data-sheet of Audio MP3 shield(Aakash) 
* Start Soldering for LED matrix and MP3 Shield 
* Start Soldering of Headers for MP3 Shield & decoder
* Environmental setup of Android & Web applications(Niket) 
* Implementation of Gesture Detection (Vidushi)
* Implementation of displaying text and basic shapes on LED Matrix (Ganesh)
|| Completed Completed Completed Completed Completed Completed 
|-
| 4 || 6 Nov 2019 || 12 Nov 2019 ||
* Implementation of OLED Driver(Niket)
* Initialization the Audio Decoder through SPI communication and read manufacturer ID 
* Implementation of random frequency bands on LED matrix (Ganesh)
* Implementation of communication Between two task(gesture_detect & LED_Display) using queues and semaphores (Vidushi)
* Display Gesture Sensor Directions on OLED in a Text (Vidushi & Niket)
* Read Song from SD Card 
|| Completed Completed Completed Completed Completed Completed 
|-
| 5 || 13 Nov 2019 || 19 Nov 2019 ||
* Circuit Simulation in Diptrace/Eagle Tool. 
* PCB Layout Design in Diptrace/Eagle Tool. 
* Finalize Components placement on PCB. 
* Read Song from SD Card and send to MP3 Shield 
* Receive Values from audio spectrum and send to display task to display on LED Matrix.(Aakash & Ganesh) 
* Interface OLED with onboard buttons to access the list of songs (Niket)
* Developing logic for the ball movement and translating hand-gesture control into LED movement.(Ganesh)
|| Completed Completed Completed Completed Completed Completed Completed 
|-
| 6 || 20 Nov 2019 || 26 Nov 2019 ||
* Interfacing of all modules sensors, bluetooth , MP3 and LED Matrix
* Test whole implementation after integration of all modules
* Test for stack overflow and system crash
* Debug and Test the Play/Pause/Stop functionality of MP3 player 
* Integrate fruit Fury game logic
* Update Final Wiki Schedule. 
|| Completed Completed Completed Completed Completed Completed Completed 
|-
| 8 || 27 Nov 2019 || 3 Dec 2019 ||
* Additional Feature week
* Establish Bluetooth communication of Device and Mobile APP 
* Develop UI on Android application. 
* Add Play/Pause/Stop and Song selection functionality to the APP. 
* Update Wiki with new details and information. 
* Enhanced game logic and integrated song play feature in game 
|| Completed Completed Completed Completed Completed 
|-
| 9 || 4 Dec 2019 || 10 Dec 2019 ||
* TESTING - CRITICAL WEEK 
* Packaging of hardware board and related components. 
* Check overall robustness of the complete system. 
* Establish complete connection on PCB 
* Update wiki with details. 
|| Completed Completed Completed Completed Completed 
|-
| 10 || 11 Dec 2019 || 17 Dec 2019 ||
* All hands on testing and final bug fixes. 
* Check for tuning or calibration of sensors if required. 
* Complete end-to-end testing for various scenarios and conditions. 
* Create the semester long project activity video and upload to YouTube. 
* Update and finalize wiki. 
|| Completed Completed Completed Completed Completed 
|-
| 11 || 18 Dec 2019 || ||
* '''DEMO: Final Project''' 
* '''SUBMISSION: Final Project Wiki''' 
|| Completed Completed 
|}

== '''Bill of Materials (General Parts)''' ==

{| class="wikitable"
|-
! scope="col" style="text-align: left;" style="background:#588ecc;" | PART NAME 

! scope="col" style="text-align: left;" style="background:#588ecc;" | 
PART MODEL & SOURCE 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
QUANTITY 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
COST PER UNIT (USD) 
|-
|
* Micro-Controller Eval-Boards
|
* LPC 4078 (Purchased from Preet Kang)
|
* 1
|
* 50.00

|-
|
* Audio decoder Breakout Board
|
* [https://www.sparkfun.com/products/12660 SparkFun MP3 Player Shield]
|
* 1
|
* 26.95

|-
|
* Audio Analyzer
|
* [https://www.amazon.com/dp/B074T9H8JV/ DFR0126 Audio Analyzer]
|
* 1
|
* 19.00

|-
|
* RGB LED matrix
|
* [https://www.sparkfun.com/products/14718 32 x 64 RGB LED Matrix Panel]
|
* 1
|
* 49.95

|-
|
* Power supply
|
* [https://www.sparkfun.com/products/15352 5V / 4A Power Supply]
|
* 1
|
* 12.95

|-
|
* Audio Speakers
|
* 3.5mm Jack Stereo Speakers
|
* 1
|
* Own

|-
|
* PCB parts and other Miscellaneous parts
|
* Anchor Electronics and Digikey '''
|
* 1
|
* 50.00

|-
|
* 2 way mirror
|
* [https://www.amazon.com/gp/product/B06Y2C79FC/ref=ppx_yo_dt_b_asin_title_o03_s00?ie=UTF8&psc=1 2-way mirror ]
|
* 1
|
* 7.64

|-
|
* PCB Fabrication
|
* [https://jlcpcb.com/quote JLCPCB]
|
* 5
|
* 29.53
|}

 

== '''Printed Circuit Board''' ==

=== Design And Architecture ===

We have designed the custom PCB using Eagle Software and as well as one prototype board in which we have connected all the modules with SJ-Two board. PCB was sent to fabrication to JLCPCB China which provided PCB with lead time of 1 week. We have implemented 2 layers of PCB with all of the parts in top layer.

'''Components Placements on PCB and on Prototype Board'''
'''1.''' One SJ-Two board is fitted onto the top of the 3D printed lid cover which with a slot opening for 2x40 IDC cable.
'''2.''' MP3 Decoder is connected with SJ-Two board and will be place on the right side of PCB and as well as on Prototype board.
'''3.''' Bluetooth Module needs only 4 pins to connect with SJ-Two and goes to UART3 and placed on the top left of the board.
'''4.''' LED Matrix is connected using 2x8 IDC cable pins on the top left side of the board.
'''5.''' Audio Frequency Analyzer is placed on the bottom side of PCB.
'''6.''' Power supply of 5v and 3.3v provisions are made on the bottom left side of PCB.

{|
[[File:Top_Layout.png|500x600px|thumb|left|Top Layer PCB Design On Eagle Software]]
|[[File:Bottom_Layout.png|500x600px|thumb|right|Bottom Layer PCB Design on Eagle Software]]
|}

{|
[[File:Top_View.png|500x600px|thumb|left|PCB Top Layer]]
|[[File:Bottom_View.png|500x600px|thumb|right|PCB Bottom Layer]]
|}

'''Infinity Mirror's Internal Circuit'''

[[File:Setup.jpeg|thumb|350x350px|center|Infinity Mirror: Internal Circuit of Embedded Entertainment Box]]

=='''Product Enclosure''' ==

To facilitate easy and convenient gaming experience and also act as an effective audio controller, a single 3D printed enclosure was designed which is spacious enough to accommodate the MCU modules like bluetooth, audio frequency analyzer and MP3 decoder on the PCB.

{|
|[[File:Top.jpeg|470px|thumb|left|Top View]]
|[[File:3D.png|430px|thumb|right|3D View]]
|}

===Final 3D Package===
[[File:Final_Setup.jpeg|thumb|600x600px|center|Infinity Mirror: Final Setup]]

=='''RGB LED Matrix'''==
A 32 x 64 RGB LED Matrix will be powered up through a 5V/4A DC adapter and is interfaced with the board to play the game 'Fruit Fury' with desired background song in the game-mode and to display the frequency bands and other relevant messages such as "Next", "Previous" and "Pause" in the music-mode. Only the INPUT IDC connector will be used because we are not cascading multiple matrices. The matrix has 2 planes (upper and lower), both of which will be programmed separately. In order to set RGB color data for each pixel in plane 1 (top half of the display) we use R1, G1 and B1 pins and for plane 2 we use R2, G2 and B2. By setting and resetting the CLOCK pulse, color data is set for every pixel in the row. Then the LATCH is set to mark end of the row and reset to move to next row. All of these steps are repeated at very less time intervals so that the human eye perceives it as one complete frame (Persistence of Vision).

Below is the description of the pins:
== Pin Configuration ==
{| class="wikitable"
|-
! scope="col"| Pin
! scope="col"| Pin Description
|-
! scope="row"| R1
| Sets upper panel's Red data
|-
! scope="row"| G1
| Sets upper panel's Green data
|-
! scope="row"| B1
| Sets upper panel's Blue data
|-
! scope="row"| R2
| Sets lower panel's Red data
|-
! scope="row"| G2
| Sets lower panel's Green data
|-
! scope="row"| B2
| Sets lower panel's Blue data
|-
! scope="row"| A
| Sets row bit 0
|-
! scope="row"| B
| Sets row bit 1
|-
! scope="row"| C
| Sets row bit 2
|-
! scope="row"| D
| Sets row bit 3
|-
! scope="row"| E
| Sets row bit 0
|-
! scope="row"| nOE
| Set to switch the LEDs off when transitioning from one row to the next
|-
! scope="row"| LATCH
| Set to mark completion of one row
|-
! scope="row"| CLK
| Set to access each pixel
|-
! scope="row"| GND
| Ground pins to be connected with board's GND.
|-
|}

Below are the technical specifications:

{| class="wikitable"
|-
! scope="col"| Spec
! scope="col"| Value
|-
| scope="row"| Pitch
| 4mm
|-
| scope="row"| Resolution
| 32 x 64 = 2048 dots
|-
| scope="row"| Panel dimensions (l x b x h) in mm
| 256 x 128 x 13
|-
| scope="row"| Working voltage/current rating
| 5v / 4A (max)
|-
| scope="row"| Scan Rate
| 1 / 16
|-
| scope="row"| Pixel component configuration (R,G,B)
| (1,1,1)
|-
| scope="row"| Weight
|0.24 kg
|-
|}

=== Hardware Design ===
The hardware involves 5V/4A DC power supply adapter, barrel jack connectors and IDC cables to power up the LED matrix and communicate with the board. Below is the pin interfacing diagram.
[[File:Slide2.png|700x900px|thumb|center|LED Matrix Pin Diagram]]

=== Software Design ===
1. '''Fruit Fury - Game mode''' 

There are 2 tasks involved to ensure functioning of the game.

a) Task 1:
*Display the game's title screen. On pressing the onboard switch (SW1), game begins.
*Also used to display game over screen / win screen.
b) Task 2:
*Enter into game mode to play the game.
*Read accelerometer values (board orientation) and render game frame.
*Detect the player's board movement, compare it with fruit's location.
*Display score, lives and smash effects.
*Press another switch (SW0) to stop game and return to title screen or to restart the game once it is over.

 '''Game rules:''' 

a) Game comprises of 3 levels (level 2 on reaching score 15 and level 3 on reaching score 30) and 5 lives in total.

b) Primary objective is to tilt the board to the direction (North West, North East, South West or South East) in which the fruit appears in order to smash it.

c) Score increases by 1 point for smashing each fruit.

d) Bombs start appearing after completion of level 1, which costs a life when hit.

e) Level 3 is faster so make sure you tune your reflexes up.

f) Reach score 50 to win the game.

 '''Bonus:''' 

a) Streaks are rewarding. Smash 10 fruits straight up to win an extra life.

b) Look out for star fruits. Hit them to gain +2 points.

Choose your song to take all the inspiration you can and start smashing!

 '''2. Music mode''' 

a) Press the button to enjoy music-only mode. Graceful audio spectrum bands are displayed that dance to the tune of the chosen song.

b) A display is prompted to the user whenever music is paused or changed to next or previous song.

=== Implementation ===
'''LED Driver'''

1. Initialize the LED matrix by configuring necessary pin directions.

2. Disable Output Enable (OE) GPIO before feeding matrix data.

3. Select the required row by setting bits on A, B, C, D GPIO pins.

4. Loop through the pixels (columns) in the selected row and set the pixel color on R, G, B GPIO pins.

5. Set zero on R, G, B GPIO pins to mask that particular pixel.

6. Set and Reset the clock for pushing the R, G, B bits for each column.

7. Issue latch to mark the row's completion and reset latch before going to next row.

8. Follow the steps 2 to 7 for other rows.

<source lang="cpp">
for (uint8_t row = 0; row < (MAX_ROW / 2); row++) {
disableOE();
set_row(row);
for (uint8_t col = 0; col < MAX_COL; col++) {
LPC_GPIO0->PIN |= (1 << CLK);
set_color_bottom(game_matrix[row + (MAX_ROW / 2)][col]);
set_color_top(game_matrix[row][col]);
LPC_GPIO0->PIN &= ~(1 << CLK);
}
LPC_GPIO0->PIN |= (1 << LAT);
LPC_GPIO0->PIN &= ~(1 << LAT);
enableOE();
vTaskDelay(1);
}
</source>

'''Fruit Fury - Game mode'''

1. Generate the fruit's initial coordinate using random function (used srand() with time value as seed to get random pattern sets).

2. Construct the LED matrix array by drawing the fruit and borders.

3. Push the entire matrix data to LED driver to display the constructed matrix frame.

4. Then read the player's orientation and match with fruit's direction.

5. Modify game parameters (score, lives and level) based on player's results.

6. Stop game if all lives are over and display game over screen by switching to game init task (Task 1).

<source lang="cpp">
/* Push button to exit game */
if (LPC_GPIO0->PIN & (1 << SW0))
is_start_game = false;

if (is_start_game == true) {
/* Generate fruit's initial coordinate position */
get_fruit_begin_coord(&row_pt, &col_pt, &quadrant);
/* Generate final frame by considering fruit object at that position */
construct_game_matrix(row_pt, col_pt);
/* Draw final frame matrix of the game */
draw_final_game_frame();
/* Get the board direction from the user and increment score count */
compute_game_params(row_pt, col_pt, quadrant);
} else
vTaskResume(display_game_init_screen_t);
</source>

'''Spectrum display - Music mode'''

1. Read the audio frequency values from the graphic equalizer task and store it as an array.

2. Based on value of each frequency band, assign a height of the band (in pixels) to be drawn on the LED matrix.

3. Set a unique color for each band.

3. Push the entire matrix data to LED driver to display the constructed matrix frame.

4. Repeat steps 1 to 3 at required intervals to display repeating bands.

<source lang="cpp">

for (row = MAX_ROW - 1; row >= 1; row--) {
for (col = 7; col <= 62; col++) {
if ((row >= (MAX_ROW - band_height[0])) && col >= 7 && col <= 13 &&
band_num <= 0) {
band_matrix[row][col] = RED;
}
if ((row >= (MAX_ROW - band_height[1])) && col >= 14 && col <= 20 &&
band_num <= 1) {
band_matrix[row][col] = GREEN;
}
if ((row >= (MAX_ROW - band_height[2])) && col >= 21 && col <= 27 &&
band_num <= 2) {
band_matrix[row][col] = YELLOW;
}
if ((row >= (MAX_ROW - band_height[3])) && col >= 28 && col <= 34 &&
band_num <= 3) {
band_matrix[row][col] = BLUE;
}
if ((row >= (MAX_ROW - band_height[4])) && col >= 35 && col <= 41 &&
band_num <= 4) {
band_matrix[row][col] = PURPLE;
}
if ((row >= (MAX_ROW - band_height[5])) && col >= 42 && col <= 48 &&
band_num <= 5) {
band_matrix[row][col] = CYAN;
}
if ((row >= (MAX_ROW - band_height[6])) && col >= 49 && col <= 55 &&
band_num <= 6) {
band_matrix[row][col] = WHITE;
}
}
}

</source>

=='''MP3 Decoder'''==

The Audio Decoder breakout board communicates with the SJ board over SPI and is interfaced with the SPI-0 pins of the SJ board as follows:

*Clock Pin (Pin 13) - SJ SPI-0 Clock Pin
*MISO Pin (Pin 12) - SJ SPI-0 MISO Pin
*MOSI Pin (Pin 11) - SJ SPI-0 MOSI Pin
*MP3 CS: Chip Select Pin for the audio decoder to be activated while sending control signals.
*MP3 DCS: Chip Select Pin for the audio decoder to be activated while sending audio data signals.
*MP3 RST: Reset pin for the audio decoder.
*MP3 DREQ: Data Request Pin. Audio decoder signals that it is ready to accept next 32 bytes of audio data.
*VCC pin - SJ 3.3V pin
*GND pin - SJ GND Pin

=== Hardware Design ===
[[File:Slide1.png|800x900px|thumb|center|MP3 Decoder Pin Diagram]]

=== Software Design ===

[[File:Mp3_fLow.png|600x500px|thumb|center|MP3 Decoder Software Design]]

=== Implementation ===

We are interfacing MP3 Decoder on the SPI0 for reading the Audio Mp3 file from the SDCard and send Mp3 data to the Decoder. The purpose of this task is to send mp3 data to the mp3 decoder. This is a high priority as it is acting as a consumer. The producer task in our project is the task that reads songs that fill the freeRTOS queue with 4KB of data. The consumer task i.e the task that sends a song to the mp3 decoder that waits on an empty queue for portMAX_DELAY. Once the queue has data, the task starts sending 32 bytes at a time to the MP3 decoder. Once 32 bytes are sent, the task waits for the DREQ pin to get high. DREQ pin high indicates that the MP3 decoder unit is ready to take 32 bytes of data. For sending data, the task acquires the MUTEX so that no other task can use the SPI bus at the same time. Once the 32 bytes are sent, the MUTEX is released. This is the working of the task.

// Task to send data to decoder(High priority)
static uint8_t bytes_to_be_sent_to_decoder[READ_BYTES_FROM_FILE];
static uint8_t current_count = 0;
uint32_t start = 0, end = 0;
while (1) {
if (0 == current_count) {
xQueueReceive(mp3_queue, &bytes_to_be_sent_to_decoder[0], portMAX_DELAY);
}
start = (current_count * TRANSMIT_BYTES_TO_DECODER);
end = ((current_count + 1) * TRANSMIT_BYTES_TO_DECODER);
while (!mp3__dreq_get_status()) {
mp3__decoder_refresh();
vTaskDelay(2);
}
if (xSemaphoreTake(mp3_mutex, portMAX_DELAY)) {
mp3__data_cs();
send_32_bytes_to_decoder_using_ssp(start, end,
&bytes_to_be_sent_to_decoder[0]);
mp3__data_ds();
xSemaphoreGive(mp3_mutex);
if (current_count == COUNT - 1) {
current_count = start = end = 0;
} else {
current_count += 1;
}}}

=='''Audio Frequency Analyzer'''==

In the audio analyser, strobe and reset pins are used to select the DC peak output. Reset high resets the multiplexer. Reset low enables the strobe pin. At the leading edge of the first strobe, the first frequency band 63Hz is on the output. On each additional leading edge strobe the next frequency band(160Hz, 400Hz, 1kHz, 2.5kHz, 6.25kHz, 16kHz) is detected.

This analyser takes input from Audio decoder for left and right side music. SJ2 controls the RS and ST pins of the "Audio Frequency Analyzer" and reads input data from S pin which is connected to ADC pin (P0.26) of SJ2 board.

*Audio Analyzer S pin -> SJ2 ADC4 pin
*Audio Analyzer RS pin -> SJ2 P0.11 pin
*Audio Analyzer ST pin -> SJ2 P2.0 pin
*Audio Analyzer + pin -> SJ2 VCC pin
*Audio Analyzer - pin -> SJ2 GND pin
<div style="clear: both"></div>

====Audio Frequency Analyser====
Audio frequency analyser is working is most important task in order to get correct value. Incorrect initialisation and in efficient delays may cause error. In this project Init and reading of data at each frequncy band is implemented based on timing diagram shown as bellow:

[[File:244 Spark TimingDiagram AudioAnalyser.jpeg|thumb|550x400px|centre|Timing Diagram of Audio Analyser]]

The software Implementation to Init frequency analyser is as follow: 
1. Select ADC pin 
2. Select GPIO pin direction for reset pin and STOBE pin 
3. Reset Audio frequency analyser 

=='''Sensors Interface'''==

We have worked on two sensors for accessing our entertainment box i.e. Gesture Sensor and Accelerometer. The SJ-Two board has both sensors on board sensor which is interfaced on the I2C bus. Accelerometers are electromechanical devices that sense either static or dynamic forces of acceleration. Static forces include gravity, while dynamic forces can include vibrations and movement. The measurements are on 3-axis and these values can be calibrated to find the desired values.

In our project, an accelerometer is for controlling Controls in the MP3 Mode like PLAY,PAUSE,PLAY Next Song and Back to Previous Song.However in Game Mode we are playing our fruit fury game using Orientation sensor for Smashing fruits coming in Directions South East, South West ,North East and North West and We were using Gesture on SJ-Two Board for gesture recognitions Left, Right, UP and Down to change the configuration in MP3 Mode but after implementation we have realised that giving gesture is more complicated then getting signals from orientation.

=== Hardware Design ===

[[File:Sensor.png|800x900px|thumb|center|APDS9960 & MMA8452Q on board Sensors]]

=== Software Design ===

[[File:Sensor_FLow.png|600x500px|thumb|center|MMA8452Q Software Design]]

=== Implementation ===
The MMA8452Q has an orientation detection algorithm with the ability to detect all six orientations but we are using only 4 orientations i.e. Portrait Up, Portrait Down,Landscape Left and Landscape Right .The transition from portrait to landscape is fixed with a 45° threshold angle and a ±14° hysteresis angle. This allows the for a smooth transition from portrait to landscape at approximately 30° and then from landscape to portrait at approximately 60°.

[[File:accel_orient.png|800x900px|thumb|center|Portrait Orientation]]

We have used the following register settings to configure the sensors and getting all 4 directions and Orientation.

[[File:APDS_Register.png|800x900px|thumb|center|Registers of APDS9960]]

 

After reading the registers we are just performing the actions as per the Orientation detected.

[[File:Accel_register.png|800x900px|thumb|center|Registers of MMA8452Q]]

 

void perform_action_on_orientation(void *p)
{
orientation_e value;
while (1)
{
value = GetOrientation();
switch (value)
{
case Portrait_UP: // Prev Song
printf("Direction Left\n");
xSemaphoreGive(sem__prev_song);
break;
case Portrait_DOWN: // Next Song
printf("Direction Right\n");
xSemaphoreGive(sem__next_song);
break;
case Landscape_LEFT: // Resume/Play/
printf("Direction Up\n");
vTaskSuspend(handle__play_song);
vTaskSuspend(handle__freq_bands);
song_status = PLAY;
break;
case Landscape_RIGHT: // Pause/Stop/Volume Decrease
printf("Direction Down\n");
vTaskResume(handle__play_song);
vTaskResume(handle__freq_bands);
song_status = PAUSE;
break;
default:
break;
}
vTaskDelay(50);
}}

=='''Bluetooth Interface'''==
The SJ-two is connected to the Bluetooth module through the Serial interface (UART3) and we have configured it at 38400 baud rate with 8-bit data and 1 stop bit using the Communication Mode. It is used to send and receive the Game and Music data from our entertainment device to an android application.

=== Hardware Design ===

[[File:Slide3.png|700x900px|thumb|center|Bluetooth Interface Pin Diagram]]

===HC-05 Bluetooth module===
HC-05 Bluetooth Module is used to set up wireless communication between the entertainment device and the Android phone. The right section of the Bluetooth Board has connection pins for power and signals as well as a 5V to 3.3V Regulator, LED, and level shifting.

'''HC-05 PinOut'''
* EN: N/A
* VCC: 5V Power
* GND: Ground
* TXD: Serial Transmit pin connected to RXD3 of SJ board
* RXD: Serial Receive pin connected to TXD3 of SJ board
* STATE: States if connected or not

=== Software Design ===

[[File:Bluetooth_Sw_diagram.png|600x500px|thumb|center|Bluetooth Software Design]]

=== Implementation ===

An accelerometer is used in the MP3 Mode to implement functionalities such as play, pause, switch to next and previous songs and volume control. In the game mode the “Fruit fury” game is played by smashing fruits appearing in the directions South East, South West, North East and North West. UART3 is used as communication protocol.The Bluetooth commands that we are using to interact with Mobile app and Device are as follows:

GAMING = 0xA1,
NORTH_EAST = 0x71,
NORTH_WEST = 0x72,
SOUTH_WEST = 0x73,
SOUTH_EAST = 0x74,
MUSIC = 0xA2,
SONG_LIST = 0xA3,
NEXT_SONG = 0xC2,
TOGGLE_SONG = 0xC1,
PREV_SONG = 0xC0,
ACK = 0x00,
NACK = 0xFF,
VOL_INC = 0xB1,
VOL_DEC = 0xB0

=='''Mobile Application'''==

{|
|[[File:Modes.jpeg|230px|thumb|List Of Feature in the APP]]
|[[File:GAME.jpeg|230px|thumb|Game Mode]]
|[[File:Mp3_song.jpeg|230px|thumb|MP3 Mode]]
|[[File:SongList.jpeg|230px|thumb|List Of Songs in SD Card]]
|}

=== Software Design ===

The Android app has been built using the cross platform framework [https://flutter.dev/ Flutter]

The app is composed of 3 parts, '''Game Mode''', '''MP3 Mode''' and '''MP3 Song List'''. On the main screen we first connect to the bluetooth before establishing connection with any of the modes. The working of each mode is explained in each subsection below.

A few variables to note in advance
ACK = 0x00, sent when successful
NACK = 0xFF, sent incase there is any error

====1. Game Mode ====

Wireless communication with the Entertainment box communication over Bluetooth protocol. Android Application is created which provides an interface to exchange data and configure the device.To enter the Game Mode screen we first check if the Bluetooth Connection is established. We send in a one byte data 0xa1 over bluetooth to the SJ2 Board and get back the response "a1$ack/nack$##" We then enter the game mode which displays a joystick that can be oriented to a direction wherever the fruit appears on the LED matrix. The corresponding orientation value is then transmitted.If the fruit had appeared in any of the quadrant then will send data from BLE APP to SJTwo Board.

'''1.''' First Quadrant (North-East): 0x71 
'''2.''' Second Quadrant (North-West): 0x72 
'''3.''' Third Quadrant (South-West): 0x73 
'''4.''' Fourth Quadrant (South-East): 0x74 

====2. MP3 Mode ====

To enter the MP3 Mode screen we first check if the Bluetooth Connection is established similar to the Game Mode. We send in one byte of data 0xa2 over bluetooth to the SJ2 Board and get back the response "a2$ack/nack$volumeInfo$currentSong$isPlaying/isPaused$##" where isPlaying is 1 and isPaused is 0. These values are loaded into the MP3 Mode Screen as initial values for the current song playing. We can then see a screen where we can control the various aspects of playing songs i.e Playing and Pausing the song, Go to next song and and Go to the previous song. We can also control the volume remotely.Controlling each part of this interface is the same as sending a single byte of data over bluetooth to the SJ2 Board.

'''1.''' Playing and Pausing Song - We just toggle the state of the Song. We issue this command by sending 0xc1 which is the Toggle State command. 
'''2.''' Next Song and Previous Song - Command for the previous and next song is 0xC0 and 0xC2. 
'''3.''' Control Volume remotely - For volume we divide the percentage 100 percent in 16 parts. We can send the value between 0xb0 to 0xbf in increments of one step. This is parsed on the SJ2 Board and converted to an equivalent volume signal. 

====3. MP3 Song List ====
To get the list of MP3 Songs which are present in the SD card, we first check if the Bluetooth Connection is established similar to the Game Mode and MP3 Song mode. We send in one byte of data 0xa3 over bluetooth to the SJ2 Board and get back the response "a3$ack/nack$data$data$...$##". APIs that were designed to read song information and data by Audio Decoder, will be used for achieving this functionality.

=='''OLED Screen'''==

[[File:Oled_screen.jpeg|thumb|600x600px|center|Oled Screen Functionality]]

=== Software Design ===

The open source package [https://github.com/olikraus/u8g2 u8g2] has been used.
There are already ready made functions for various OLED Drivers. The indepth setup guide can be found [https://github.com/olikraus/u8g2/wiki/u8g2setupc here]

=== Implementation ===

The u8g2 library is a very robust library which means that this code can be extended for any microcontroller as long as the interface is written properly.

We needed to write 2 main functions, outlined below, i.e byte_cb and gpio_and_delay_cb using the function prototype `uint8_t u8x8_lpc_gpio_and_delay(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr)`.

Since the SJ2 Board is connected to the OLED Screen on the SPI1 Bus we also need to write the SPI1 driver, mainly a method to that sends data over SPI to the Slave device i.e the OLED Screen

=== Initializing the u8g2 for LPC4078 ===

<source lang="cpp">

// Created a file `u8g2_wrapper.h

static gpio_s dc;
static u8g2_t u8g2;

void u8g2_wrapper__init(gpio_s *dc_pin) {
u8g2_Setup_ssd1306_128x64_vcomh0_1(&u8g2, U8G2_R0, u8x8_byte_4wire_hw_spi, u8x8_lpc_gpio_and_delay);
u8g2_InitDisplay(&u8g2);
u8g2_SetPowerSave(&u8g2, 0);

dc.pin_number = dc_pin->pin_number;
dc.port_number = dc_pin->port_number;
}

u8g2_t *u8g2_wrapper__get_instance() { return &u8g2; }

uint8_t u8x8_lpc_gpio_and_delay(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr) {
switch (msg) {
case U8X8_MSG_GPIO_AND_DELAY_INIT:
delay__ms(1);
break;
case U8X8_MSG_DELAY_MILLI:
delay__ms(arg_int);
break;
case U8X8_MSG_GPIO_DC:
// DONE, Write to the GPIO_DC Pin
if (arg_int == 0) {
gpio__reset(dc);
} else {
gpio__set(dc);
}
break;
case U8X8_MSG_GPIO_RESET:
break;
}
return 1;
}

uint8_t u8x8_byte_4wire_hw_spi(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr) {
uint8_t *data;
switch (msg) {
case U8X8_MSG_BYTE_SEND:
data = (uint8_t *)arg_ptr;
while (arg_int > 0) {
ussp1__exchange_byte((uint8_t)*data);
data++;
arg_int--;
}
break;
case U8X8_MSG_BYTE_INIT:
break;
case U8X8_MSG_BYTE_SET_DC:
if (arg_int == 0) {
gpio__reset(dc);
} else {
gpio__set(dc);
}
break;
case U8X8_MSG_BYTE_START_TRANSFER:
break;
case U8X8_MSG_BYTE_END_TRANSFER:
break;
default:
return 0;
}
return 1;
}

</source>

=='''Technical Challenges'''==

1. '''RGB LED Matrix''' 

* Getting control of the matrix was challenging as it needs to follow specific sequence of pin enabling/disabling at appropriate timing.

* Setting right delays to avoid flickers and get smooth transitioning between frames by using delays or for loops.

* Fixing high CPU utilization by changing delay__us to vTaskDelay.

* Designing elements of the game (title screen and fruit objects) which required careful plotting of pixel data.

2. '''Audio Decoder''' 

* The CPU utilization for sending a song task was very high (80% +).
* In order to reduce the utilization, we gave the vTaskDelay(1) while waiting for the DREQ to be high. The high DREQ indicates that the decoder is ready to receive next 32 bytes of data. So meanwhile, when the DREQ pin is low, we made task to sleep for vTaskDelay(1). After doing this, we significantly reduced the CPU utilization to 15%. We tried with vTaskDelay(2) to get CPU utilization of 10%.
* We further tried to make the CPU utilization below 10%. This was really a tough challenge, and figured out that the actual SPI clock is 1Mhz which is too slow as SPI is meant to operate at much higher speed. We changed the clock rate of SPI to 12MHz but the song speed was too slow. We checked the datasheet of the Mp3 decoder and set the internal clock multiplier to 4.5x. This make the shield operate at high clock rates at 12.XX Mhz. So keeping this in mind we made the SPI speed to 12MHz which is safe. We successfully achieved CPU utilization of 5-6% which is very much in the acceptable range.

3. '''PCB Designing''' 

* We realized that using GPP for long term is not a good idea. Initially we spent time in debugging our hardware and later we have realized like we can’t take this for our final day.
* We did multiple reviews before ordering our final PCB as none of us did that earlier. We have faced issue in manual routing on Eagle Autodesk but our ISA Prashant helped us and he reviewed our PCB design twice.

4. '''Mobile Application''' 

* The main challenge of the Mobile application was to make the UI interactive while getting data asynchronously over the Bluetooth module.
* There was a global listener stream implemented that got the value and concatenate the string till we received the end frame (##).
* However the challenge still existed to know which screen has called what data which prompted us to create the key and ACK/NACK pair in the start.
* The Mobile app is completely data reactive, which means that the UI components render and change according to the data provided. This caused a lot of issues mainly since we tried polling methods to make sure that the UI remains up to date with the STATE of the SJ2 Board.
* A manual approach was opted for mainly to make the system more deterministic and for better debugging capabilities.

=='''Suggestions for Future Students'''==
 '''RGB LED Matrix''' 

* To begin with, focus on writing a simple driver to get control of 1 pixel at a targeted location and then use appropriate loops to light up the entire row/column.

* Make sure all pixels are able to light up with all possible colors to eliminate hardware defects.

* Try with minimum / no delays, print tick counts and then come up with meaningful delay numbers.

* Optimize the code (minimum delays, avoiding repetitive function calls, etc.) to bring down the CPU usage level.

* Use the link in the references to draw desired elements and generate the matrix.

 '''Tips for getting GOOD Grades and to remain in top 3 teams''' 
* Select your teammates wisely, and make sure every one dedicates themself for this project.
* Be an active member of your team and review rubrics for the final DEMO.
* As soon as the professor mentions the project, please start working on the project otherwise, in the end, you have to struggle with finals and you will be left with less time for testing and you have to struggle in demo.

 '''General tips''' 
* Remember the KISS approach when you code. (Keep It Simple and Stupid).
* For this project, one should know the basics in C/ C++, FreeRTOS, and some good debugging skills. Because if you don't have one, you will eventually end up spending more time debugging your problem.
* Always give meaningful names to the variable or the function, so a third person reviewing the code gets an overall idea by just reading the name.

=='''Conclusion'''==
It was a really great working experience for all of us. We were really thrilled from the beginning that we will be working on something that is quite relevant in the industries. We worked as a team of four which helped us all to know the importance of team-work and co-ordination. We learned many great stuff like

* State Design using FreeRTOS
* FreeRTOS APIS when task handles are NULL vs when Initialised.
* Uses of extern and global variables as opposed to encapsulation i.e static inside private 'c' files.
* Learning Optimization through the integration of our peer's individual modules
* Improving CPU utilisation of the main LED and MP3 tasks.
* Workload sharing and cooperation amongst peers.
* Sharing ideas and debugging a common problem together i.e team building.
* We realised that using GPP for long term is not a good idea, there were some breakdown in the wires and our MP3 stopped working. Initially we spent a lot of time debugging hardware and doing soldering. So we started designing the PCB, and when our PCB was done, we spent hardly any time debugging the hardware.
* Git : We learnt all the basic of GIT and it plays an important to role for source code versioning.

There were a lot of problems while doing this project but it was a steep learning curve. In the end we were able to achieve our objective with really good results.

=='''Project Video'''==
https://youtu.be/vVjHCoyWYz4

=='''Project Source Code'''==
* Git Project Link (Individual Modules): [https://gitlab.com/Infinity_Mirror/infinity_mirror-cmpe-244]
* Git Project Link: [https://gitlab.com/ganeshram2493/infi_mirror]

=='''Project Presentation File'''==
* [https://drive.google.com/file/d/1Q_Xvs-a2feQcr-FbPEKbwmlhi35hqNxX/view?usp=sharing Presentation Link]

=='''References'''==
=== Acknowledgement ===

We would like to express our gratitude to Professor Preetpal Kang for generously sharing his time and knowledge with us and guiding us through the completion of this project. We would also like to thank the Prashant Gandhi(ISA) for their valuable advice and constructive feedback.

=== References Used ===

====== Flutter Android GUI ======
* [https://material.io/resources/icons/?style=baseline Material Design Icons]
* [https://flutter.dev/ Building a Dynamic UI with Flutter]
* [https://www.youtube.com/channel/UCwXdFgeE9KYzlDdR7TG9cMw Flutter Youtube Channel]

====== RGB LED Matrix Interfacing and Designing ======
* [https://www.sparkfun.com/products/14718 Datasheet and Hookup guide]
* [https://cdn-learn.adafruit.com/downloads/pdf/32x16-32x32-rgb-led-matrix.pdf?timestamp=1543806512/ Wiring and pin information]
* [https://www.riyas.org/2013/12/online-led-matrix-font-generator-with.html Hex code generator to build LED matrix models]

====== MP3 Decoder and Frequency Analyzer ======
* [https://www.sparkfun.com/datasheets/Components/General/MSGEQ7.pdf Seven Band Graphic Equalizer MSGEQ7 Data Sheet]
* [https://www.kr4.us/SparkFun-MP3-Player-Shield.html?gclid=EAIaIQobChMIov3f7PWc2wIVDtVkCh0-rgStEAYYASABEgIEgPD_BwE SparkFun-MP3-Player-Shield Datasheet]

====== Gesture & Orientation Sensors ======
* [https://cdn.sparkfun.com/assets/learn_tutorials/3/2/1/Avago-APDS-9960-datasheet.pdf Gesture Sensor Data Sheet]
* [https://learn.sparkfun.com/tutorials/mma8452q-accelerometer-breakout-hookup-guide/all Accelerometer Sensor Data]

====== General/Miscellaneous ======
* [http://socialledge.com/sjsu/index.php/FreeRTOS_Tutorial FreeRTOS Tutorial]
* [https://sjsu-dev2.readthedocs.io/en/latest/?badge=latest SJTwo-c Documentation]

F19: Infinity Mirror

2019-12-18T23:52:10Z

Proj user22: /* Pin Configuration */

== '''Abstract''' ==

The main theme of the project is to build an interactive embedded system consisting of two entertainment modes - Music and Gaming. On the music mode, the MP3 decoder module reads songs from an SD card on the MCU board and plays the music through a speaker. It deals with the convergence of various services such as playing a game with background music, control volume, switch and pause/play songs. While the song is being played, audio frequency spectrum bands based on music tune are displayed on the LED Matrix band visualization etc. On the game mode, a fruit smashing game called “Fruit Fury” is implemented where the user needs to orient the MCU board in a direction according to where the fruit appears on the LED matrix. Alongside, the user can listen and switch songs. To achieve the above functionalities, various elements such as Audio Decoder, Audio frequency analyzer, 32x64 RGB LED Matrix and HC-05 bluetooth module and Android application are integrated.

[[File:High_level1.png|800px|thumb|center|Block Diagram of Infinity Mirror]]

== '''Introduction & Objectives''' ==

The key features supported by the system is real-time orientation recognition & trigger respective actions in 2 modes - MP3 mode and Game mode.

MP3 MODE:

1. Determine the accelerometer sensor values based on the orientation of the board and perform music control such as play, pause, volume control and changing songs.

2. In response, retrieve the data from the SD Card & communicate to the audio decoder for appropriate audio streaming.

3. Also implemented interaction with HC-05 bluetooth module through a customized mobile application and provide same operations.

4. Display frequency spectrum bands in sync to the tune of the song played.

[[File:frequency_bands.png|800px|thumb|center|Frequency bands]]

GAME MODE - Fruit Fury:

1. Determine the accelerometer sensor values based on the orientation of the board and hit the fruit in corresponding direction.

2. Incorporating provision on the board's switches to change to next or previous song.

3. Also implemented interaction with HC-05 bluetooth module through a customized mobile application and play the game through the same.

[[File:Title Screen.jpeg|800px|thumb|center|Title Screen]]

'''Project Objectives'''
'''1. Audio Decoder''' - Fetches song data from the SD card and plays it over a speaker.
'''2. RGB LED Matrix''' - Display frequency bands on music mode or view the game on game mode.
'''3. Audio Frequency Analyzer''' - To convert the audio data into 7 spectrum bands which is then displayed as individual colored bands on the LED matrix.
'''4. Bluetooth HC-05''' - Interfaces the system using Bluetooth to an Android application.

'''Team Objectives'''
'''1.''' Learn each and every module as much as possible, in order to develop an overall product.
'''2.''' Understand the proper use of queues and semaphores in order to send/receive the data between multiple tasks.
'''3.''' Learn to integrate all modules and ensuring smooth transition, communication and context switching at desired time intervals.
'''4.''' Document and track all the bugs encountered during development and learn to update git repository after every fix.

== '''Team Members & Technical Responsibilities''' ==
[[File:cmpe244_F19_Infinity_Mirror_members.jpeg|thumb|500x500px|TEAM INFINITY MIRROR|right]]

*'''''[http://linkedin.com/in/aakash-chitroda-17841740 Aakash Chitroda]'''''
** MP3 Audio Encoder/Decoder
** Audio frequency Analyzer logic

*'''''[https://www.linkedin.com/in/ganeshram93 Ganesh Ram]'''''
** Interfacing of LED Matrix and driver design
** Game logic design
** Audio frequency spectrum logic on LED
** Packaging

*'''''[https://www.linkedin.com/in/niket-naidu-30090a134/ Niket Naidu]'''''
** Android & Bluetooth Application
** OLED Interfacing and Designing
** PCB Design improvements
** Accelerometer Sensor integration with OLED Screen

*'''''[https://www.linkedin.com/in/vidushi-jain-048b992a Vidushi Jain]'''''
** Bluetooth Communication
** Interfacing of Gesture & Accelerometer Sensors
** Hardware Designing & PCB Integration

 

== '''Administrative Responsibilities''' ==
{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|- style="vertical-align: top;"
! colspan="5" style="background:#588ecc" | Administrative Roles 
|-
! style="text-align: left;" |
* Team Lead 
| Aakash Chitroda 
|-
! style="text-align: left;" |
* Finance Manager
| Niket Naidu 
|-
! style="text-align: left;" |
* Git Repository Manager 
| Vidushi Jain 
|-
! style="text-align: left;" |
* Wiki Report Manager 
| Vidushi Jain 
 Ganesh Ram 
|-
! style="text-align: left;" |
* Bill of Materials Manager 
| Ganesh Ram 
|}

== '''Team Deliverables Schedule''' ==

{| class="wikitable"
|-
! scope="col" style="text-align: left;" style="background:#588ecc;" | WEEK
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
START DATE 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
END DATE 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
TASK DETAILS 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
STATUS 
|-
| 1 || 15 Oct 2019 || 22 Oct 2019 ||
*Create and establish GitLab repository
*Establish slack channel and invite Preet
*Look through previous years projects and study it
*Distribute major roles among team members
|| Completed Completed Completed Completed 
|-
| 2 || 23 Oct 2019 || 29 Oct 2019 ||
* Create a Bill of Materials 
* Select and order Parts 
* Review Data-sheet and Interfacing Of LED Matrix(Ganesh) 
* Review Data-sheet for Gesture sensor(Vidushi) 
* Make Repo on Gitlab for all modules - Follow Naming Convention. 
|| Completed Completed Completed Completed Completed 
|-
| 3 || 30 Oct 2019 || 5 Nov 2019 ||
* Review Data-sheet of Audio MP3 shield(Aakash) 
* Start Soldering for LED matrix and MP3 Shield 
* Start Soldering of Headers for MP3 Shield & decoder
* Environmental setup of Android & Web applications(Niket) 
* Implementation of Gesture Detection (Vidushi)
* Implementation of displaying text and basic shapes on LED Matrix (Ganesh)
|| Completed Completed Completed Completed Completed Completed 
|-
| 4 || 6 Nov 2019 || 12 Nov 2019 ||
* Implementation of OLED Driver(Niket)
* Initialization the Audio Decoder through SPI communication and read manufacturer ID 
* Implementation of random frequency bands on LED matrix (Ganesh)
* Implementation of communication Between two task(gesture_detect & LED_Display) using queues and semaphores (Vidushi)
* Display Gesture Sensor Directions on OLED in a Text (Vidushi & Niket)
* Read Song from SD Card 
|| Completed Completed Completed Completed Completed Completed 
|-
| 5 || 13 Nov 2019 || 19 Nov 2019 ||
* Circuit Simulation in Diptrace/Eagle Tool. 
* PCB Layout Design in Diptrace/Eagle Tool. 
* Finalize Components placement on PCB. 
* Read Song from SD Card and send to MP3 Shield 
* Receive Values from audio spectrum and send to display task to display on LED Matrix.(Aakash & Ganesh) 
* Interface OLED with onboard buttons to access the list of songs (Niket)
* Developing logic for the ball movement and translating hand-gesture control into LED movement.(Ganesh)
|| Completed Completed Completed Completed Completed Completed Completed 
|-
| 6 || 20 Nov 2019 || 26 Nov 2019 ||
* Interfacing of all modules sensors, bluetooth , MP3 and LED Matrix
* Test whole implementation after integration of all modules
* Test for stack overflow and system crash
* Debug and Test the Play/Pause/Stop functionality of MP3 player 
* Integrate fruit Fury game logic
* Update Final Wiki Schedule. 
|| Completed Completed Completed Completed Completed Completed Completed 
|-
| 8 || 27 Nov 2019 || 3 Dec 2019 ||
* Additional Feature week
* Establish Bluetooth communication of Device and Mobile APP 
* Develop UI on Android application. 
* Add Play/Pause/Stop and Song selection functionality to the APP. 
* Update Wiki with new details and information. 
* Enhanced game logic and integrated song play feature in game 
|| Completed Completed Completed Completed Completed 
|-
| 9 || 4 Dec 2019 || 10 Dec 2019 ||
* TESTING - CRITICAL WEEK 
* Packaging of hardware board and related components. 
* Check overall robustness of the complete system. 
* Establish complete connection on PCB 
* Update wiki with details. 
|| Completed Completed Completed Completed Completed 
|-
| 10 || 11 Dec 2019 || 17 Dec 2019 ||
* All hands on testing and final bug fixes. 
* Check for tuning or calibration of sensors if required. 
* Complete end-to-end testing for various scenarios and conditions. 
* Create the semester long project activity video and upload to YouTube. 
* Update and finalize wiki. 
|| Completed Completed Completed Completed Completed 
|-
| 11 || 18 Dec 2019 || ||
* '''DEMO: Final Project''' 
* '''SUBMISSION: Final Project Wiki''' 
|| Completed Completed 
|}

== '''Bill of Materials (General Parts)''' ==

{| class="wikitable"
|-
! scope="col" style="text-align: left;" style="background:#588ecc;" | PART NAME 

! scope="col" style="text-align: left;" style="background:#588ecc;" | 
PART MODEL & SOURCE 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
QUANTITY 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
COST PER UNIT (USD) 
|-
|
* Micro-Controller Eval-Boards
|
* LPC 4078 (Purchased from Preet Kang)
|
* 1
|
* 50.00

|-
|
* Audio decoder Breakout Board
|
* [https://www.sparkfun.com/products/12660 SparkFun MP3 Player Shield]
|
* 1
|
* 26.95

|-
|
* Audio Analyzer
|
* [https://www.amazon.com/dp/B074T9H8JV/ DFR0126 Audio Analyzer]
|
* 1
|
* 19.00

|-
|
* RGB LED matrix
|
* [https://www.sparkfun.com/products/14718 32 x 64 RGB LED Matrix Panel]
|
* 1
|
* 49.95

|-
|
* Power supply
|
* [https://www.sparkfun.com/products/15352 5V / 4A Power Supply]
|
* 1
|
* 12.95

|-
|
* Audio Speakers
|
* 3.5mm Jack Stereo Speakers
|
* 1
|
* Own

|-
|
* PCB parts and other Miscellaneous parts
|
* Anchor Electronics and Digikey '''
|
* 1
|
* 50.00

|-
|
* 2 way mirror
|
* [https://www.amazon.com/gp/product/B06Y2C79FC/ref=ppx_yo_dt_b_asin_title_o03_s00?ie=UTF8&psc=1 2-way mirror ]
|
* 1
|
* 7.64

|-
|
* PCB Fabrication
|
* [https://jlcpcb.com/quote JLCPCB]
|
* 5
|
* 29.53
|}

 

== '''Printed Circuit Board''' ==

=== Design And Architecture ===

We have designed the custom PCB using Eagle Software and as well as one prototype board in which we have connected all the modules with SJ-Two board. PCB was sent to fabrication to JLCPCB China which provided PCB with lead time of 1 week. We have implemented 2 layers of PCB with all of the parts in top layer.

'''Components Placements on PCB and on Prototype Board'''
'''1.''' One SJ-Two board is fitted onto the top of the 3D printed lid cover which with a slot opening for 2x40 IDC cable.
'''2.''' MP3 Decoder is connected with SJ-Two board and will be place on the right side of PCB and as well as on Prototype board.
'''3.''' Bluetooth Module needs only 4 pins to connect with SJ-Two and goes to UART3 and placed on the top left of the board.
'''4.''' LED Matrix is connected using 2x8 IDC cable pins on the top left side of the board.
'''5.''' Audio Frequency Analyzer is placed on the bottom side of PCB.
'''6.''' Power supply of 5v and 3.3v provisions are made on the bottom left side of PCB.

{|
[[File:Top_Layout.png|500x600px|thumb|left|Top Layer PCB Design On Eagle Software]]
|[[File:Bottom_Layout.png|500x600px|thumb|right|Bottom Layer PCB Design on Eagle Software]]
|}

{|
[[File:Top_View.png|500x600px|thumb|left|PCB Top Layer]]
|[[File:Bottom_View.png|500x600px|thumb|right|PCB Bottom Layer]]
|}

'''Infinity Mirror's Internal Circuit'''

[[File:Setup.jpeg|thumb|350x350px|center|Infinity Mirror: Internal Circuit of Embedded Entertainment Box]]

=='''Product Enclosure''' ==

To facilitate easy and convenient gaming experience and also act as an effective audio controller, a single 3D printed enclosure was designed which is spacious enough to accommodate the MCU modules like bluetooth, audio frequency analyzer and MP3 decoder on the PCB.

{|
|[[File:Top.jpeg|470px|thumb|left|Top View]]
|[[File:3D.png|430px|thumb|right|3D View]]
|}

===Final 3D Package===
[[File:Final_Setup.jpeg|thumb|600x600px|center|Infinity Mirror: Final Setup]]

=='''RGB LED Matrix'''==
A 32 x 64 RGB LED Matrix will be powered up through a 5V/4A DC adapter and is interfaced with the board to play the game 'Fruit Fury' with desired background song in the game-mode and to display the frequency bands and other relevant messages such as "Next", "Previous" and "Pause" in the music-mode. Only the INPUT IDC connector will be used because we are not cascading multiple matrices. The matrix has 2 planes (upper and lower), both of which will be programmed separately. In order to set RGB color data for each pixel in plane 1 (top half of the display) we use R1, G1 and B1 pins and for plane 2 we use R2, G2 and B2. By setting and resetting the CLOCK pulse, color data is set for every pixel in the row. Then the LATCH is set to mark end of the row and reset to move to next row. All of these steps are repeated at very less time intervals so that the human eye perceives it as one complete frame (Persistence of Vision).

Below is the description of the pins:
== Pin Configuration ==
{| class="wikitable"
|-
! scope="col"| Pin
! scope="col"| Pin Description
|-
! scope="row"| R1
| Sets upper panel's Red data
|-
! scope="row"| G1
| Sets upper panel's Green data
|-
! scope="row"| B1
| Sets upper panel's Blue data
|-
! scope="row"| R2
| Sets lower panel's Red data
|-
! scope="row"| G2
| Sets lower panel's Green data
|-
! scope="row"| B2
| Sets lower panel's Blue data
|-
! scope="row"| A
| Sets row bit 0
|-
! scope="row"| B
| Sets row bit 1
|-
! scope="row"| C
| Sets row bit 2
|-
! scope="row"| D
| Sets row bit 3
|-
! scope="row"| E
| Sets row bit 0
|-
! scope="row"| nOE
| Set to switch the LEDs off when transitioning from one row to the next
|-
! scope="row"| LATCH
| Set to mark completion of one row
|-
! scope="row"| CLK
| Set to access each pixel
|-
! scope="row"| GND
| Ground pins to be connected with board's GND.
|-
|}

Below are the technical specifications:

{| class="wikitable"
|-
! scope="col"| Spec
! scope="col"| Value
|-
| scope="row"| Pitch
| 4mm
|-
| scope="row"| Resolution
| 32 x 64 = 2048 dots
|-
| scope="row"| Panel dimensions (l x b x h) in mm
| 256 x 128 x 13
|-
| scope="row"| Working voltage/current rating
| 5v / 4A (max)
|-
| scope="row"| Scan Rate
| 1 / 16
|-
| scope="row"| Pixel component configuration (R,G,B)
| (1,1,1)
|-
| scope="row"| Weight
|0.24 kg
|-
|}

=== Hardware Design ===
The hardware involves 5V/4A DC power supply adapter, barrel jack connectors and IDC cables to power up the LED matrix and communicate with the board. Below is the pin interfacing diagram.
[[File:Slide2.png|700x900px|thumb|center|LED Matrix Pin Diagram]]

=== Software Design ===
1. '''Fruit Fury - Game mode''' 

There are 2 tasks involved to ensure functioning of the game.

a) Task 1:
*Display the game's title screen. On pressing the onboard switch (SW1), game begins.
*Also used to display game over screen / win screen.
b) Task 2:
*Enter into game mode to play the game.
*Read accelerometer values (board orientation) and render game frame.
*Detect the player's board movement, compare it with fruit's location.
*Display score, lives and smash effects.
*Press another switch (SW0) to stop game and return to title screen or to restart the game once it is over.

 '''Game rules:''' 

a) Game comprises of 3 levels (level 2 on reaching score 15 and level 3 on reaching score 30) and 5 lives in total.

b) Primary objective is to tilt the board to the direction (North West, North East, South West or South East) in which the fruit appears in order to smash it.

c) Score increases by 1 point for smashing each fruit.

d) Bombs start appearing after completion of level 1, which costs a life when hit.

e) Level 3 is faster so make sure you tune your reflexes up.

f) Reach score 50 to win the game.

 '''Bonus:''' 

a) Streaks are rewarding. Smash 10 fruits straight up to win an extra life.

b) Look out for star fruits. Hit them to gain +2 points.

Choose your song to take all the inspiration you can and start smashing!

 '''2. Music mode''' 

a) Press the button to enjoy music-only mode. Graceful audio spectrum bands are displayed that dance to the tune of the chosen song.

b) A display is prompted to the user whenever music is paused or changed to next or previous song.

=== Implementation ===
'''LED Driver'''

1. Initialize the LED matrix by configuring necessary pin directions.

2. Disable Output Enable (OE) GPIO before feeding matrix data.

3. Select the required row by setting bits on A, B, C, D GPIO pins.

4. Loop through the pixels (columns) in the selected row and set the pixel color on R, G, B GPIO pins.

5. Set zero on R, G, B GPIO pins to mask that particular pixel.

6. Set and Reset the clock for pushing the R, G, B bits for each column.

7. Issue latch to mark the row's completion and reset latch before going to next row.

8. Follow the steps 2 to 7 for other rows.

<source lang="cpp">
for (uint8_t row = 0; row < (MAX_ROW / 2); row++) {
disableOE();
set_row(row);
for (uint8_t col = 0; col < MAX_COL; col++) {
LPC_GPIO0->PIN |= (1 << CLK);
set_color_bottom(game_matrix[row + (MAX_ROW / 2)][col]);
set_color_top(game_matrix[row][col]);
LPC_GPIO0->PIN &= ~(1 << CLK);
}
LPC_GPIO0->PIN |= (1 << LAT);
LPC_GPIO0->PIN &= ~(1 << LAT);
enableOE();
vTaskDelay(1);
}
</source>

'''Fruit Fury - Game mode'''

1. Generate the fruit's initial coordinate using random function (used srand() with time value as seed to get random pattern sets).

2. Construct the LED matrix array by drawing the fruit and borders.

3. Push the entire matrix data to LED driver to display the constructed matrix frame.

4. Then read the player's orientation and match with fruit's direction.

5. Modify game parameters (score, lives and level) based on player's results.

6. Stop game if all lives are over and display game over screen by switching to game init task (Task 1).

<source lang="cpp">
/* Push button to exit game */
if (LPC_GPIO0->PIN & (1 << SW0))
is_start_game = false;

if (is_start_game == true) {
/* Generate fruit's initial coordinate position */
get_fruit_begin_coord(&row_pt, &col_pt, &quadrant);
/* Generate final frame by considering fruit object at that position */
construct_game_matrix(row_pt, col_pt);
/* Draw final frame matrix of the game */
draw_final_game_frame();
/* Get the board direction from the user and increment score count */
compute_game_params(row_pt, col_pt, quadrant);
} else
vTaskResume(display_game_init_screen_t);
</source>

'''Spectrum display - Music mode'''

1. Read the audio frequency values from the graphic equalizer task and store it as an array.

2. Based on value of each frequency band, assign a height of the band (in pixels) to be drawn on the LED matrix.

3. Set a unique color for each band.

3. Push the entire matrix data to LED driver to display the constructed matrix frame.

4. Repeat steps 1 to 3 at required intervals to display repeating bands.

<source lang="cpp">

for (row = MAX_ROW - 1; row >= 1; row--) {
for (col = 7; col <= 62; col++) {
if ((row >= (MAX_ROW - band_height[0])) && col >= 7 && col <= 13 &&
band_num <= 0) {
band_matrix[row][col] = RED;
}
if ((row >= (MAX_ROW - band_height[1])) && col >= 14 && col <= 20 &&
band_num <= 1) {
band_matrix[row][col] = GREEN;
}
if ((row >= (MAX_ROW - band_height[2])) && col >= 21 && col <= 27 &&
band_num <= 2) {
band_matrix[row][col] = YELLOW;
}
if ((row >= (MAX_ROW - band_height[3])) && col >= 28 && col <= 34 &&
band_num <= 3) {
band_matrix[row][col] = BLUE;
}
if ((row >= (MAX_ROW - band_height[4])) && col >= 35 && col <= 41 &&
band_num <= 4) {
band_matrix[row][col] = PURPLE;
}
if ((row >= (MAX_ROW - band_height[5])) && col >= 42 && col <= 48 &&
band_num <= 5) {
band_matrix[row][col] = CYAN;
}
if ((row >= (MAX_ROW - band_height[6])) && col >= 49 && col <= 55 &&
band_num <= 6) {
band_matrix[row][col] = WHITE;
}
}
}

</source>

=='''MP3 Decoder'''==

The Audio Decoder breakout board communicates with the SJ board over SPI and is interfaced with the SPI-0 pins of the SJ board as follows:

*Clock Pin (Pin 13) - SJ SPI-0 Clock Pin
*MISO Pin (Pin 12) - SJ SPI-0 MISO Pin
*MOSI Pin (Pin 11) - SJ SPI-0 MOSI Pin
*MP3 CS: Chip Select Pin for the audio decoder to be activated while sending control signals.
*MP3 DCS: Chip Select Pin for the audio decoder to be activated while sending audio data signals.
*MP3 RST: Reset pin for the audio decoder.
*MP3 DREQ: Data Request Pin. Audio decoder signals that it is ready to accept next 32 bytes of audio data.
*VCC pin - SJ 3.3V pin
*GND pin - SJ GND Pin

=== Hardware Design ===
[[File:Slide1.png|800x900px|thumb|center|MP3 Decoder Pin Diagram]]

=== Software Design ===

[[File:Mp3_fLow.png|600x500px|thumb|center|MP3 Decoder Software Design]]

=== Implementation ===

We are interfacing MP3 Decoder on the SPI0 for reading the Audio Mp3 file from the SDCard and send Mp3 data to the Decoder. The purpose of this task is to send mp3 data to the mp3 decoder. This is a high priority as it is acting as a consumer. The producer task in our project is the task that reads songs that fill the freeRTOS queue with 4KB of data. The consumer task i.e the task that sends a song to the mp3 decoder that waits on an empty queue for portMAX_DELAY. Once the queue has data, the task starts sending 32 bytes at a time to the MP3 decoder. Once 32 bytes are sent, the task waits for the DREQ pin to get high. DREQ pin high indicates that the MP3 decoder unit is ready to take 32 bytes of data. For sending data, the task acquires the MUTEX so that no other task can use the SPI bus at the same time. Once the 32 bytes are sent, the MUTEX is released. This is the working of the task.

// Task to send data to decoder(High priority)
static uint8_t bytes_to_be_sent_to_decoder[READ_BYTES_FROM_FILE];
static uint8_t current_count = 0;
uint32_t start = 0, end = 0;
while (1) {
if (0 == current_count) {
xQueueReceive(mp3_queue, &bytes_to_be_sent_to_decoder[0], portMAX_DELAY);
}
start = (current_count * TRANSMIT_BYTES_TO_DECODER);
end = ((current_count + 1) * TRANSMIT_BYTES_TO_DECODER);
while (!mp3__dreq_get_status()) {
mp3__decoder_refresh();
vTaskDelay(2);
}
if (xSemaphoreTake(mp3_mutex, portMAX_DELAY)) {
mp3__data_cs();
send_32_bytes_to_decoder_using_ssp(start, end,
&bytes_to_be_sent_to_decoder[0]);
mp3__data_ds();
xSemaphoreGive(mp3_mutex);
if (current_count == COUNT - 1) {
current_count = start = end = 0;
} else {
current_count += 1;
}}}

=='''Audio Frequency Analyzer'''==

In the audio analyser, strobe and reset pins are used to select the DC peak output. Reset high resets the multiplexer. Reset low enables the strobe pin. At the leading edge of the first strobe, the first frequency band 63Hz is on the output. On each additional leading edge strobe the next frequency band(160Hz, 400Hz, 1kHz, 2.5kHz, 6.25kHz, 16kHz) is detected.

This analyser takes input from Audio decoder for left and right side music. SJ2 controls the RS and ST pins of the "Audio Frequency Analyzer" and reads input data from S pin which is connected to ADC pin (P0.26) of SJ2 board.

*Audio Analyzer S pin -> SJ2 ADC4 pin
*Audio Analyzer RS pin -> SJ2 P0.11 pin
*Audio Analyzer ST pin -> SJ2 P2.0 pin
*Audio Analyzer + pin -> SJ2 VCC pin
*Audio Analyzer - pin -> SJ2 GND pin
<div style="clear: both"></div>

====Audio Frequency Analyser====
Audio frequency analyser is working is most important task in order to get correct value. Incorrect initialisation and in efficient delays may cause error. In this project Init and reading of data at each frequncy band is implemented based on timing diagram shown as bellow:

[[File:244 Spark TimingDiagram AudioAnalyser.jpeg|thumb|550x400px|centre|Timing Diagram of Audio Analyser]]

The software Implementation to Init frequency analyser is as follow: 
1. Select ADC pin 
2. Select GPIO pin direction for reset pin and STOBE pin 
3. Reset Audio frequency analyser 

=='''Sensors Interface'''==

We have worked on two sensors for accessing our entertainment box i.e. Gesture Sensor and Accelerometer. The SJ-Two board has both sensors on board sensor which is interfaced on the I2C bus. Accelerometers are electromechanical devices that sense either static or dynamic forces of acceleration. Static forces include gravity, while dynamic forces can include vibrations and movement. The measurements are on 3-axis and these values can be calibrated to find the desired values.

In our project, an accelerometer is for controlling Controls in the MP3 Mode like PLAY,PAUSE,PLAY Next Song and Back to Previous Song.However in Game Mode we are playing our fruit fury game using Orientation sensor for Smashing fruits coming in Directions South East, South West ,North East and North West and We were using Gesture on SJ-Two Board for gesture recognitions Left, Right, UP and Down to change the configuration in MP3 Mode but after implementation we have realised that giving gesture is more complicated then getting signals from orientation.

=== Hardware Design ===

[[File:Sensor.png|800x900px|thumb|center|APDS9960 & MMA8452Q on board Sensors]]

=== Software Design ===

[[File:Sensor_FLow.png|600x500px|thumb|center|MMA8452Q Software Design]]

=== Implementation ===
The MMA8452Q has an orientation detection algorithm with the ability to detect all six orientations but we are using only 4 orientations i.e. Portrait Up, Portrait Down,Landscape Left and Landscape Right .The transition from portrait to landscape is fixed with a 45° threshold angle and a ±14° hysteresis angle. This allows the for a smooth transition from portrait to landscape at approximately 30° and then from landscape to portrait at approximately 60°.

[[File:accel_orient.png|800x900px|thumb|center|Portrait Orientation]]

We have used the following register settings to configure the sensors and getting all 4 directions and Orientation.

[[File:APDS_Register.png|800x900px|thumb|center|Registers of APDS9960]]

 

After reading the registers we are just performing the actions as per the Orientation detected.

[[File:Accel_register.png|800x900px|thumb|center|Registers of MMA8452Q]]

 

void perform_action_on_orientation(void *p)
{
orientation_e value;
while (1)
{
value = GetOrientation();
switch (value)
{
case Portrait_UP: // Prev Song
printf("Direction Left\n");
xSemaphoreGive(sem__prev_song);
break;
case Portrait_DOWN: // Next Song
printf("Direction Right\n");
xSemaphoreGive(sem__next_song);
break;
case Landscape_LEFT: // Resume/Play/
printf("Direction Up\n");
vTaskSuspend(handle__play_song);
vTaskSuspend(handle__freq_bands);
song_status = PLAY;
break;
case Landscape_RIGHT: // Pause/Stop/Volume Decrease
printf("Direction Down\n");
vTaskResume(handle__play_song);
vTaskResume(handle__freq_bands);
song_status = PAUSE;
break;
default:
break;
}
vTaskDelay(50);
}}

=='''Bluetooth Interface'''==
The SJ-two is connected to the Bluetooth module through the Serial interface (UART3) and we have configured it at 38400 baud rate with 8-bit data and 1 stop bit using the Communication Mode. It is used to send and receive the Game and Music data from our entertainment device to an android application.

=== Hardware Design ===

[[File:Slide3.png|700x900px|thumb|center|Bluetooth Interface Pin Diagram]]

===HC-05 Bluetooth module===
HC-05 Bluetooth Module is used to set up wireless communication between the entertainment device and the Android phone. The right section of the Bluetooth Board has connection pins for power and signals as well as a 5V to 3.3V Regulator, LED, and level shifting.

'''HC-05 PinOut'''
* EN: N/A
* VCC: 5V Power
* GND: Ground
* TXD: Serial Transmit pin connected to RXD3 of SJ board
* RXD: Serial Receive pin connected to TXD3 of SJ board
* STATE: States if connected or not

=== Software Design ===

[[File:Bluetooth_Sw_diagram.png|600x500px|thumb|center|Bluetooth Software Design]]

=== Implementation ===

An accelerometer is used in the MP3 Mode to implement functionalities such as play, pause, switch to next and previous songs and volume control. In the game mode the “Fruit fury” game is played by smashing fruits appearing in the directions South East, South West, North East and North West. UART3 is used as communication protocol.The Bluetooth commands that we are using to interact with Mobile app and Device are as follows:

GAMING = 0xA1,
NORTH_EAST = 0x71,
NORTH_WEST = 0x72,
SOUTH_WEST = 0x73,
SOUTH_EAST = 0x74,
MUSIC = 0xA2,
SONG_LIST = 0xA3,
NEXT_SONG = 0xC2,
TOGGLE_SONG = 0xC1,
PREV_SONG = 0xC0,
ACK = 0x00,
NACK = 0xFF,
VOL_INC = 0xB1,
VOL_DEC = 0xB0

=='''Mobile Application'''==

{|
|[[File:Modes.jpeg|230px|thumb|List Of Feature in the APP]]
|[[File:GAME.jpeg|230px|thumb|Game Mode]]
|[[File:Mp3_song.jpeg|230px|thumb|MP3 Mode]]
|[[File:SongList.jpeg|230px|thumb|List Of Songs in SD Card]]
|}

=== Software Design ===

The Android app has been built using the cross platform framework [https://flutter.dev/ Flutter]

The app is composed of 3 parts, '''Game Mode''', '''MP3 Mode''' and '''MP3 Song List'''. On the main screen we first connect to the bluetooth before establishing connection with any of the modes. The working of each mode is explained in each subsection below.

A few variables to note in advance
ACK = 0x00, sent when successful
NACK = 0xFF, sent incase there is any error

====1. Game Mode ====

Wireless communication with the Entertainment box communication over Bluetooth protocol. Android Application is created which provides an interface to exchange data and configure the device.To enter the Game Mode screen we first check if the Bluetooth Connection is established. We send in a one byte data 0xa1 over bluetooth to the SJ2 Board and get back the response "a1$ack/nack$##" We then enter the game mode which displays a joystick that can be oriented to a direction wherever the fruit appears on the LED matrix. The corresponding orientation value is then transmitted.If the fruit had appeared in any of the quadrant then will send data from BLE APP to SJTwo Board.

'''1.''' First Quadrant (North-East): 0x71 
'''2.''' Second Quadrant (North-West): 0x72 
'''3.''' Third Quadrant (South-West): 0x73 
'''4.''' Fourth Quadrant (South-East): 0x74 

====2. MP3 Mode ====

To enter the MP3 Mode screen we first check if the Bluetooth Connection is established similar to the Game Mode. We send in one byte of data 0xa2 over bluetooth to the SJ2 Board and get back the response "a2$ack/nack$volumeInfo$currentSong$isPlaying/isPaused$##" where isPlaying is 1 and isPaused is 0. These values are loaded into the MP3 Mode Screen as initial values for the current song playing. We can then see a screen where we can control the various aspects of playing songs i.e Playing and Pausing the song, Go to next song and and Go to the previous song. We can also control the volume remotely.Controlling each part of this interface is the same as sending a single byte of data over bluetooth to the SJ2 Board.

'''1.''' Playing and Pausing Song - We just toggle the state of the Song. We issue this command by sending 0xc1 which is the Toggle State command. 
'''2.''' Next Song and Previous Song - Command for the previous and next song is 0xC0 and 0xC2. 
'''3.''' Control Volume remotely - For volume we divide the percentage 100 percent in 16 parts. We can send the value between 0xb0 to 0xbf in increments of one step. This is parsed on the SJ2 Board and converted to an equivalent volume signal. 

====3. MP3 Song List ====
To get the list of MP3 Songs which are present in the SD card, we first check if the Bluetooth Connection is established similar to the Game Mode and MP3 Song mode. We send in one byte of data 0xa3 over bluetooth to the SJ2 Board and get back the response "a3$ack/nack$data$data$...$##". APIs that were designed to read song information and data by Audio Decoder, will be used for achieving this functionality.

=='''OLED Screen'''==

[[File:Oled_screen.jpeg|thumb|600x600px|center|Oled Screen Functionality]]

=== Software Design ===

The open source package [https://github.com/olikraus/u8g2 u8g2] has been used.
There are already ready made functions for various OLED Drivers. The indepth setup guide can be found [https://github.com/olikraus/u8g2/wiki/u8g2setupc here]

=== Implementation ===

The u8g2 library is a very robust library which means that this code can be extended for any microcontroller as long as the interface is written properly.

We needed to write 2 main functions, outlined below, i.e byte_cb and gpio_and_delay_cb using the function prototype `uint8_t u8x8_lpc_gpio_and_delay(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr)`.

Since the SJ2 Board is connected to the OLED Screen on the SPI1 Bus we also need to write the SPI1 driver, mainly a method to that sends data over SPI to the Slave device i.e the OLED Screen

=== Initializing the u8g2 for LPC4078 ===

<source lang="cpp">

// Created a file `u8g2_wrapper.h

static gpio_s dc;
static u8g2_t u8g2;

void u8g2_wrapper__init(gpio_s *dc_pin) {
u8g2_Setup_ssd1306_128x64_vcomh0_1(&u8g2, U8G2_R0, u8x8_byte_4wire_hw_spi, u8x8_lpc_gpio_and_delay);
u8g2_InitDisplay(&u8g2);
u8g2_SetPowerSave(&u8g2, 0);

dc.pin_number = dc_pin->pin_number;
dc.port_number = dc_pin->port_number;
}

u8g2_t *u8g2_wrapper__get_instance() { return &u8g2; }

uint8_t u8x8_lpc_gpio_and_delay(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr) {
switch (msg) {
case U8X8_MSG_GPIO_AND_DELAY_INIT:
delay__ms(1);
break;
case U8X8_MSG_DELAY_MILLI:
delay__ms(arg_int);
break;
case U8X8_MSG_GPIO_DC:
// DONE, Write to the GPIO_DC Pin
if (arg_int == 0) {
gpio__reset(dc);
} else {
gpio__set(dc);
}
break;
case U8X8_MSG_GPIO_RESET:
break;
}
return 1;
}

uint8_t u8x8_byte_4wire_hw_spi(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr) {
uint8_t *data;
switch (msg) {
case U8X8_MSG_BYTE_SEND:
data = (uint8_t *)arg_ptr;
while (arg_int > 0) {
ussp1__exchange_byte((uint8_t)*data);
data++;
arg_int--;
}
break;
case U8X8_MSG_BYTE_INIT:
break;
case U8X8_MSG_BYTE_SET_DC:
if (arg_int == 0) {
gpio__reset(dc);
} else {
gpio__set(dc);
}
break;
case U8X8_MSG_BYTE_START_TRANSFER:
break;
case U8X8_MSG_BYTE_END_TRANSFER:
break;
default:
return 0;
}
return 1;
}

</source>

=='''Technical Challenges'''==

1. '''RGB LED Matrix''' 

* Getting control of the matrix was challenging as it needs to follow specific sequence of pin enabling/disabling at appropriate timing.

* Setting right delays to avoid flickers and get smooth transitioning between frames by using delays or for loops.

* Fixing high CPU utilization by changing delay__us to vTaskDelay.

* Designing elements of the game (title screen and fruit objects) which required careful plotting of pixel data.

2. '''Audio Decoder''' 

* The CPU utilization for sending a song task was very high (80% +).
* In order to reduce the utilization, we gave the vTaskDelay(1) while waiting for the DREQ to be high. The high DREQ indicates that the decoder is ready to receive next 32 bytes of data. So meanwhile, when the DREQ pin is low, we made task to sleep for vTaskDelay(1). After doing this, we significantly reduced the CPU utilization to 15%. We tried with vTaskDelay(2) to get CPU utilization of 10%.
* We further tried to make the CPU utilization below 10%. This was really a tough challenge, and figured out that the actual SPI clock is 1Mhz which is too slow as SPI is meant to operate at much higher speed. We changed the clock rate of SPI to 12MHz but the song speed was too slow. We checked the datasheet of the Mp3 decoder and set the internal clock multiplier to 4.5x. This make the shield operate at high clock rates at 12.XX Mhz. So keeping this in mind we made the SPI speed to 12MHz which is safe. We successfully achieved CPU utilization of 5-6% which is very much in the acceptable range.

3. '''PCB Designing''' 

* We realized that using GPP for long term is not a good idea. Initially we spent time in debugging our hardware and later we have realized like we can’t take this for our final day.
* We did multiple reviews before ordering our final PCB as none of us did that earlier. We have faced issue in manual routing on Eagle Autodesk but our ISA Prashant helped us and he reviewed our PCB design twice.

4. '''Mobile Application''' 

* The main challenge of the Mobile application was to make the UI interactive while getting data asynchronously over the Bluetooth module.
* There was a global listener stream implemented that got the value and concatenate the string till we received the end frame (##).
* However the challenge still existed to know which screen has called what data which prompted us to create the key and ACK/NACK pair in the start.
* The Mobile app is completely data reactive, which means that the UI components render and change according to the data provided. This caused a lot of issues mainly since we tried polling methods to make sure that the UI remains up to date with the STATE of the SJ2 Board.
* A manual approach was opted for mainly to make the system more deterministic and for better debugging capabilities.

=='''Suggestions for Future Students'''==
 '''RGB LED Matrix''' 

* To begin with, focus on writing a simple driver to get control of 1 pixel at a targeted location and then use appropriate loops to light up the entire row/column.

* Make sure all pixels are able to light up with all possible colors to eliminate hardware defects.

* Try with minimum / no delays, print tick counts and then come up with meaningful delay numbers.

* Optimize the code (minimum delays, avoiding repetitive function calls, etc.) to bring down the CPU usage level.

* Use the link in the references to draw desired elements and generate the matrix.

 '''Tips for getting GOOD Grades and to remain in top 3 teams''' 
* Select your teammates wisely, and make sure every one dedicates themself for this project.
* Be an active member of your team and review rubrics for the final DEMO.
* As soon as the professor mentions the project, please start working on the project otherwise, in the end, you have to struggle with finals and you will be left with less time for testing and you have to struggle in demo.

 '''General tips''' 
* Remember the KISS approach when you code. (Keep It Simple and Stupid).
* For this project, one should know the basics in C/ C++, FreeRTOS, and some good debugging skills. Because if you don't have one, you will eventually end up spending more time debugging your problem.
* Always give meaningful names to the variable or the function, so a third person reviewing the code gets an overall idea by just reading the name.

=='''Conclusion'''==
It was a really great working experience for all of us. We were really thrilled from the beginning that we will be working on something that is quite relevant in the industries. We worked as a team of four which helped us all to know the importance of team-work and co-ordination. We learned many great stuff like

* State Design using FreeRTOS
* FreeRTOS APIS when task handles are NULL vs when Initialised.
* Uses of extern and global variables as opposed to encapsulation i.e static inside private 'c' files.
* Learning Optimization through the integration of our peer's individual modules
* Improving CPU utilisation of the main LED and MP3 tasks.
* Workload sharing and cooperation amongst peers.
* Sharing ideas and debugging a common problem together i.e team building.
* We realised that using GPP for long term is not a good idea, there were some breakdown in the wires and our MP3 stopped working. Initially we spent a lot of time debugging hardware and doing soldering. So we started designing the PCB, and when our PCB was done, we spent hardly any time debugging the hardware.
* Git : We learnt all the basic of GIT and it plays an important to role for source code versioning.

There were a lot of problems while doing this project but it was a steep learning curve. In the end we were able to achieve our objective with really good results.

=='''Project Video'''==
https://youtu.be/vVjHCoyWYz4

=='''Project Source Code'''==
* Git Project Link (Individual Modules): [https://gitlab.com/Infinity_Mirror/infinity_mirror-cmpe-244]
* Git Project Link: [https://gitlab.com/ganeshram2493/infi_mirror]

=='''Project Presentation File'''==
* [https://drive.google.com/file/d/1Q_Xvs-a2feQcr-FbPEKbwmlhi35hqNxX/view?usp=sharing Presentation Link]

=='''References'''==
=== Acknowledgement ===

We would like to express our gratitude to Professor Preetpal Kang for generously sharing his time and knowledge with us and guiding us through the completion of this project. We would also like to thank the Prashant Gandhi(ISA) for their valuable advice and constructive feedback.

=== References Used ===

====== Flutter Android GUI ======
* [https://material.io/resources/icons/?style=baseline Material Design Icons]
* [https://flutter.dev/ Building a Dynamic UI with Flutter]
* [https://www.youtube.com/channel/UCwXdFgeE9KYzlDdR7TG9cMw Flutter Youtube Channel]

====== RGB LED Matrix Interfacing and Designing ======
* [https://www.sparkfun.com/products/14718 Datasheet and Hookup guide]
* [https://cdn-learn.adafruit.com/downloads/pdf/32x16-32x32-rgb-led-matrix.pdf?timestamp=1543806512/ Wiring and pin information]
* [https://www.riyas.org/2013/12/online-led-matrix-font-generator-with.html Hex code generator to build LED matrix models]

====== MP3 Decoder and Frequency Analyzer ======
* [https://www.sparkfun.com/datasheets/Components/General/MSGEQ7.pdf Seven Band Graphic Equalizer MSGEQ7 Data Sheet]
* [https://www.kr4.us/SparkFun-MP3-Player-Shield.html?gclid=EAIaIQobChMIov3f7PWc2wIVDtVkCh0-rgStEAYYASABEgIEgPD_BwE SparkFun-MP3-Player-Shield Datasheet]

====== Gesture & Orientation Sensors ======
* [https://cdn.sparkfun.com/assets/learn_tutorials/3/2/1/Avago-APDS-9960-datasheet.pdf Gesture Sensor Data Sheet]
* [https://learn.sparkfun.com/tutorials/mma8452q-accelerometer-breakout-hookup-guide/all Accelerometer Sensor Data]

====== General/Miscellaneous ======
* [http://socialledge.com/sjsu/index.php/FreeRTOS_Tutorial FreeRTOS Tutorial]
* [https://sjsu-dev2.readthedocs.io/en/latest/?badge=latest SJTwo-c Documentation]

F19: Infinity Mirror

2019-12-18T23:46:25Z

Proj user22: /* Technical Challenges */

== '''Abstract''' ==

The main theme of the project is to build an interactive embedded system consisting of two entertainment modes - Music and Gaming. On the music mode, the MP3 decoder module reads songs from an SD card on the MCU board and plays the music through a speaker. It deals with the convergence of various services such as playing a game with background music, control volume, switch and pause/play songs. While the song is being played, audio frequency spectrum bands based on music tune are displayed on the LED Matrix band visualization etc. On the game mode, a fruit smashing game called “Fruit Fury” is implemented where the user needs to orient the MCU board in a direction according to where the fruit appears on the LED matrix. Alongside, the user can listen and switch songs. To achieve the above functionalities, various elements such as Audio Decoder, Audio frequency analyzer, 32x64 RGB LED Matrix and HC-05 bluetooth module and Android application are integrated.

[[File:High_level1.png|800px|thumb|center|Block Diagram of Infinity Mirror]]

== '''Introduction & Objectives''' ==

The key features supported by the system is real-time orientation recognition & trigger respective actions in 2 modes - MP3 mode and Game mode.

MP3 MODE:

1. Determine the accelerometer sensor values based on the orientation of the board and perform music control such as play, pause, volume control and changing songs.

2. In response, retrieve the data from the SD Card & communicate to the audio decoder for appropriate audio streaming.

3. Also implemented interaction with HC-05 bluetooth module through a customized mobile application and provide same operations.

4. Display frequency spectrum bands in sync to the tune of the song played.

[[File:frequency_bands.png|800px|thumb|center|Frequency bands]]

GAME MODE - Fruit Fury:

1. Determine the accelerometer sensor values based on the orientation of the board and hit the fruit in corresponding direction.

2. Incorporating provision on the board's switches to change to next or previous song.

3. Also implemented interaction with HC-05 bluetooth module through a customized mobile application and play the game through the same.

[[File:Title Screen.jpeg|800px|thumb|center|Title Screen]]

'''Project Objectives'''
'''1. Audio Decoder''' - Fetches song data from the SD card and plays it over a speaker.
'''2. RGB LED Matrix''' - Display frequency bands on music mode or view the game on game mode.
'''3. Audio Frequency Analyzer''' - To convert the audio data into 7 spectrum bands which is then displayed as individual colored bands on the LED matrix.
'''4. Bluetooth HC-05''' - Interfaces the system using Bluetooth to an Android application.

'''Team Objectives'''
'''1.''' Learn each and every module as much as possible, in order to develop an overall product.
'''2.''' Understand the proper use of queues and semaphores in order to send/receive the data between multiple tasks.
'''3.''' Learn to integrate all modules and ensuring smooth transition, communication and context switching at desired time intervals.
'''4.''' Document and track all the bugs encountered during development and learn to update git repository after every fix.

== '''Team Members & Technical Responsibilities''' ==
[[File:cmpe244_F19_Infinity_Mirror_members.jpeg|thumb|500x500px|TEAM INFINITY MIRROR|right]]

*'''''[http://linkedin.com/in/aakash-chitroda-17841740 Aakash Chitroda]'''''
** MP3 Audio Encoder/Decoder
** Audio frequency Analyzer logic

*'''''[https://www.linkedin.com/in/ganeshram93 Ganesh Ram]'''''
** Interfacing of LED Matrix and driver design
** Game logic design
** Audio frequency spectrum logic on LED
** Packaging

*'''''[https://www.linkedin.com/in/niket-naidu-30090a134/ Niket Naidu]'''''
** Android & Bluetooth Application
** OLED Interfacing and Designing
** PCB Design improvements
** Accelerometer Sensor integration with OLED Screen

*'''''[https://www.linkedin.com/in/vidushi-jain-048b992a Vidushi Jain]'''''
** Bluetooth Communication
** Interfacing of Gesture & Accelerometer Sensors
** Hardware Designing & PCB Integration

 

== '''Administrative Responsibilities''' ==
{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|- style="vertical-align: top;"
! colspan="5" style="background:#588ecc" | Administrative Roles 
|-
! style="text-align: left;" |
* Team Lead 
| Aakash Chitroda 
|-
! style="text-align: left;" |
* Finance Manager
| Niket Naidu 
|-
! style="text-align: left;" |
* Git Repository Manager 
| Vidushi Jain 
|-
! style="text-align: left;" |
* Wiki Report Manager 
| Vidushi Jain 
 Ganesh Ram 
|-
! style="text-align: left;" |
* Bill of Materials Manager 
| Ganesh Ram 
|}

== '''Team Deliverables Schedule''' ==

{| class="wikitable"
|-
! scope="col" style="text-align: left;" style="background:#588ecc;" | WEEK
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
START DATE 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
END DATE 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
TASK DETAILS 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
STATUS 
|-
| 1 || 15 Oct 2019 || 22 Oct 2019 ||
*Create and establish GitLab repository
*Establish slack channel and invite Preet
*Look through previous years projects and study it
*Distribute major roles among team members
|| Completed Completed Completed Completed 
|-
| 2 || 23 Oct 2019 || 29 Oct 2019 ||
* Create a Bill of Materials 
* Select and order Parts 
* Review Data-sheet and Interfacing Of LED Matrix(Ganesh) 
* Review Data-sheet for Gesture sensor(Vidushi) 
* Make Repo on Gitlab for all modules - Follow Naming Convention. 
|| Completed Completed Completed Completed Completed 
|-
| 3 || 30 Oct 2019 || 5 Nov 2019 ||
* Review Data-sheet of Audio MP3 shield(Aakash) 
* Start Soldering for LED matrix and MP3 Shield 
* Start Soldering of Headers for MP3 Shield & decoder
* Environmental setup of Android & Web applications(Niket) 
* Implementation of Gesture Detection (Vidushi)
* Implementation of displaying text and basic shapes on LED Matrix (Ganesh)
|| Completed Completed Completed Completed Completed Completed 
|-
| 4 || 6 Nov 2019 || 12 Nov 2019 ||
* Implementation of OLED Driver(Niket)
* Initialization the Audio Decoder through SPI communication and read manufacturer ID 
* Implementation of random frequency bands on LED matrix (Ganesh)
* Implementation of communication Between two task(gesture_detect & LED_Display) using queues and semaphores (Vidushi)
* Display Gesture Sensor Directions on OLED in a Text (Vidushi & Niket)
* Read Song from SD Card 
|| Completed Completed Completed Completed Completed Completed 
|-
| 5 || 13 Nov 2019 || 19 Nov 2019 ||
* Circuit Simulation in Diptrace/Eagle Tool. 
* PCB Layout Design in Diptrace/Eagle Tool. 
* Finalize Components placement on PCB. 
* Read Song from SD Card and send to MP3 Shield 
* Receive Values from audio spectrum and send to display task to display on LED Matrix.(Aakash & Ganesh) 
* Interface OLED with onboard buttons to access the list of songs (Niket)
* Developing logic for the ball movement and translating hand-gesture control into LED movement.(Ganesh)
|| Completed Completed Completed Completed Completed Completed Completed 
|-
| 6 || 20 Nov 2019 || 26 Nov 2019 ||
* Interfacing of all modules sensors, bluetooth , MP3 and LED Matrix
* Test whole implementation after integration of all modules
* Test for stack overflow and system crash
* Debug and Test the Play/Pause/Stop functionality of MP3 player 
* Integrate fruit Fury game logic
* Update Final Wiki Schedule. 
|| Completed Completed Completed Completed Completed Completed Completed 
|-
| 8 || 27 Nov 2019 || 3 Dec 2019 ||
* Additional Feature week
* Establish Bluetooth communication of Device and Mobile APP 
* Develop UI on Android application. 
* Add Play/Pause/Stop and Song selection functionality to the APP. 
* Update Wiki with new details and information. 
* Enhanced game logic and integrated song play feature in game 
|| Completed Completed Completed Completed Completed 
|-
| 9 || 4 Dec 2019 || 10 Dec 2019 ||
* TESTING - CRITICAL WEEK 
* Packaging of hardware board and related components. 
* Check overall robustness of the complete system. 
* Establish complete connection on PCB 
* Update wiki with details. 
|| Completed Completed Completed Completed Completed 
|-
| 10 || 11 Dec 2019 || 17 Dec 2019 ||
* All hands on testing and final bug fixes. 
* Check for tuning or calibration of sensors if required. 
* Complete end-to-end testing for various scenarios and conditions. 
* Create the semester long project activity video and upload to YouTube. 
* Update and finalize wiki. 
|| Completed Completed Completed Completed Completed 
|-
| 11 || 18 Dec 2019 || ||
* '''DEMO: Final Project''' 
* '''SUBMISSION: Final Project Wiki''' 
|| Completed Completed 
|}

== '''Bill of Materials (General Parts)''' ==

{| class="wikitable"
|-
! scope="col" style="text-align: left;" style="background:#588ecc;" | PART NAME 

! scope="col" style="text-align: left;" style="background:#588ecc;" | 
PART MODEL & SOURCE 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
QUANTITY 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
COST PER UNIT (USD) 
|-
|
* Micro-Controller Eval-Boards
|
* LPC 4078 (Purchased from Preet Kang)
|
* 1
|
* 50.00

|-
|
* Audio decoder Breakout Board
|
* [https://www.sparkfun.com/products/12660 SparkFun MP3 Player Shield]
|
* 1
|
* 26.95

|-
|
* Audio Analyzer
|
* [https://www.amazon.com/dp/B074T9H8JV/ DFR0126 Audio Analyzer]
|
* 1
|
* 19.00

|-
|
* RGB LED matrix
|
* [https://www.sparkfun.com/products/14718 32 x 64 RGB LED Matrix Panel]
|
* 1
|
* 49.95

|-
|
* Power supply
|
* [https://www.sparkfun.com/products/15352 5V / 4A Power Supply]
|
* 1
|
* 12.95

|-
|
* Audio Speakers
|
* 3.5mm Jack Stereo Speakers
|
* 1
|
* Own

|-
|
* PCB parts and other Miscellaneous parts
|
* Anchor Electronics and Digikey '''
|
* 1
|
* 50.00

|-
|
* 2 way mirror
|
* [https://www.amazon.com/gp/product/B06Y2C79FC/ref=ppx_yo_dt_b_asin_title_o03_s00?ie=UTF8&psc=1 2-way mirror ]
|
* 1
|
* 7.64

|-
|
* PCB Fabrication
|
* [https://jlcpcb.com/quote JLCPCB]
|
* 5
|
* 29.53
|}

 

== '''Printed Circuit Board''' ==

=== Design And Architecture ===

We have designed the custom PCB using Eagle Software and as well as one prototype board in which we have connected all the modules with SJ-Two board. PCB was sent to fabrication to JLCPCB China which provided PCB with lead time of 1 week. We have implemented 2 layers of PCB with all of the parts in top layer.

'''Components Placements on PCB and on Prototype Board'''
'''1.''' One SJ-Two board is fitted onto the top of the 3D printed lid cover which with a slot opening for 2x40 IDC cable.
'''2.''' MP3 Decoder is connected with SJ-Two board and will be place on the right side of PCB and as well as on Prototype board.
'''3.''' Bluetooth Module needs only 4 pins to connect with SJ-Two and goes to UART3 and placed on the top left of the board.
'''4.''' LED Matrix is connected using 2x8 IDC cable pins on the top left side of the board.
'''5.''' Audio Frequency Analyzer is placed on the bottom side of PCB.
'''6.''' Power supply of 5v and 3.3v provisions are made on the bottom left side of PCB.

{|
[[File:Top_Layout.png|500x600px|thumb|left|Top Layer PCB Design On Eagle Software]]
|[[File:Bottom_Layout.png|500x600px|thumb|right|Bottom Layer PCB Design on Eagle Software]]
|}

{|
[[File:Top_View.png|500x600px|thumb|left|PCB Top Layer]]
|[[File:Bottom_View.png|500x600px|thumb|right|PCB Bottom Layer]]
|}

'''Infinity Mirror's Internal Circuit'''

[[File:Setup.jpeg|thumb|350x350px|center|Infinity Mirror: Internal Circuit of Embedded Entertainment Box]]

=='''Product Enclosure''' ==

To facilitate easy and convenient gaming experience and also act as an effective audio controller, a single 3D printed enclosure was designed which is spacious enough to accommodate the MCU modules like bluetooth, audio frequency analyzer and MP3 decoder on the PCB.

{|
|[[File:Top.jpeg|470px|thumb|left|Top View]]
|[[File:3D.png|430px|thumb|right|3D View]]
|}

===Final 3D Package===
[[File:Final_Setup.jpeg|thumb|600x600px|center|Infinity Mirror: Final Setup]]

=='''RGB LED Matrix'''==
A 32 x 64 RGB LED Matrix will be powered up through a 5V/4A DC adapter and is interfaced with the board to play the game 'Fruit Fury' with desired background song in the game-mode and to display the frequency bands and other relevant messages such as "Next", "Previous" and "Pause" in the music-mode. Only the INPUT IDC connector will be used because we are not cascading multiple matrices. The matrix has 2 planes (upper and lower), both of which will be programmed separately. In order to set RGB color data for each pixel in plane 1 (top half of the display) we use R1, G1 and B1 pins and for plane 2 we use R2, G2 and B2. By setting and resetting the CLOCK pulse, color data is set for every pixel in the row. Then the LATCH is set to mark end of the row and reset to move to next row. All of these steps are repeated at very less time intervals so that the human eye perceives it as one complete frame (Persistence of Vision).

Below is the description of the pins:
== Pin Configuration ==
{| class="wikitable"
|-
! scope="col"| Pin
! scope="col"| Pin Desciption
|-
! scope="row"| R1
| Sets upper panel's Red data
|-
! scope="row"| G1
| Sets upper panel's Green data
|-
! scope="row"| B1
| Sets upper panel's Blue data
|-
! scope="row"| R2
| Sets lower panel's Red data
|-
! scope="row"| G2
| Sets lower panel's Green data
|-
! scope="row"| B2
| Sets lower panel's Blue data
|-
! scope="row"| A
| Sets row bit 0
|-
! scope="row"| B
| Sets row bit 1
|-
! scope="row"| C
| Sets row bit 2
|-
! scope="row"| D
| Sets row bit 3
|-
! scope="row"| E
| Sets row bit 0
|-
! scope="row"| nOE
| Set to switch the LEDs off when transitioning from one row to the next
|-
! scope="row"| LATCH
| Set to mark completion of one row
|-
! scope="row"| CLK
| Set to access each pixel
|-
! scope="row"| GND
| Ground pins to be connected with board's GND.
|-
|}

Below are the technical specifications:

*Pitch -> 4 mm
*Resolution -> 32 x 64 = 2048 dots
*Panel dimensions (l x b x h) in mm -> 256 x 128 x 13
*Working voltage/current rating -> 5v / 4A (max)
*Scan rate - 1/16
*Pixel component configuration (R,G,B) -> 1,1,1
*Weight -> 0.24 kg

=== Hardware Design ===
The hardware involves 5V/4A DC power supply adapter, barrel jack connectors and IDC cables to power up the LED matrix and communicate with the board. Below is the pin interfacing diagram.
[[File:Slide2.png|700x900px|thumb|center|LED Matrix Pin Diagram]]

=== Software Design ===
1. '''Fruit Fury - Game mode''' 

There are 2 tasks involved to ensure functioning of the game.

a) Task 1:
*Display the game's title screen. On pressing the onboard switch (SW1), game begins.
*Also used to display game over screen / win screen.
b) Task 2:
*Enter into game mode to play the game.
*Read accelerometer values (board orientation) and render game frame.
*Detect the player's board movement, compare it with fruit's location.
*Display score, lives and smash effects.
*Press another switch (SW0) to stop game and return to title screen or to restart the game once it is over.

 '''Game rules:''' 

a) Game comprises of 3 levels (level 2 on reaching score 15 and level 3 on reaching score 30) and 5 lives in total.

b) Primary objective is to tilt the board to the direction (North West, North East, South West or South East) in which the fruit appears in order to smash it.

c) Score increases by 1 point for smashing each fruit.

d) Bombs start appearing after completion of level 1, which costs a life when hit.

e) Level 3 is faster so make sure you tune your reflexes up.

f) Reach score 50 to win the game.

 '''Bonus:''' 

a) Streaks are rewarding. Smash 10 fruits straight up to win an extra life.

b) Look out for star fruits. Hit them to gain +2 points.

Choose your song to take all the inspiration you can and start smashing!

 '''2. Music mode''' 

a) Press the button to enjoy music-only mode. Graceful audio spectrum bands are displayed that dance to the tune of the chosen song.

b) A display is prompted to the user whenever music is paused or changed to next or previous song.

=== Implementation ===
'''LED Driver'''

1. Initialize the LED matrix by configuring necessary pin directions.

2. Disable Output Enable (OE) GPIO before feeding matrix data.

3. Select the required row by setting bits on A, B, C, D GPIO pins.

4. Loop through the pixels (columns) in the selected row and set the pixel color on R, G, B GPIO pins.

5. Set zero on R, G, B GPIO pins to mask that particular pixel.

6. Set and Reset the clock for pushing the R, G, B bits for each column.

7. Issue latch to mark the row's completion and reset latch before going to next row.

8. Follow the steps 2 to 7 for other rows.

<source lang="cpp">
for (uint8_t row = 0; row < (MAX_ROW / 2); row++) {
disableOE();
set_row(row);
for (uint8_t col = 0; col < MAX_COL; col++) {
LPC_GPIO0->PIN |= (1 << CLK);
set_color_bottom(game_matrix[row + (MAX_ROW / 2)][col]);
set_color_top(game_matrix[row][col]);
LPC_GPIO0->PIN &= ~(1 << CLK);
}
LPC_GPIO0->PIN |= (1 << LAT);
LPC_GPIO0->PIN &= ~(1 << LAT);
enableOE();
vTaskDelay(1);
}
</source>

'''Fruit Fury - Game mode'''

1. Generate the fruit's initial coordinate using random function (used srand() with time value as seed to get random pattern sets).

2. Construct the LED matrix array by drawing the fruit and borders.

3. Push the entire matrix data to LED driver to display the constructed matrix frame.

4. Then read the player's orientation and match with fruit's direction.

5. Modify game parameters (score, lives and level) based on player's results.

6. Stop game if all lives are over and display game over screen by switching to game init task (Task 1).

<source lang="cpp">
/* Push button to exit game */
if (LPC_GPIO0->PIN & (1 << SW0))
is_start_game = false;

if (is_start_game == true) {
/* Generate fruit's initial coordinate position */
get_fruit_begin_coord(&row_pt, &col_pt, &quadrant);
/* Generate final frame by considering fruit object at that position */
construct_game_matrix(row_pt, col_pt);
/* Draw final frame matrix of the game */
draw_final_game_frame();
/* Get the board direction from the user and increment score count */
compute_game_params(row_pt, col_pt, quadrant);
} else
vTaskResume(display_game_init_screen_t);
</source>

'''Spectrum display - Music mode'''

1. Read the audio frequency values from the graphic equalizer task and store it as an array.

2. Based on value of each frequency band, assign a height of the band (in pixels) to be drawn on the LED matrix.

3. Set a unique color for each band.

3. Push the entire matrix data to LED driver to display the constructed matrix frame.

4. Repeat steps 1 to 3 at required intervals to display repeating bands.

<source lang="cpp">

for (row = MAX_ROW - 1; row >= 1; row--) {
for (col = 7; col <= 62; col++) {
if ((row >= (MAX_ROW - band_height[0])) && col >= 7 && col <= 13 &&
band_num <= 0) {
band_matrix[row][col] = RED;
}
if ((row >= (MAX_ROW - band_height[1])) && col >= 14 && col <= 20 &&
band_num <= 1) {
band_matrix[row][col] = GREEN;
}
if ((row >= (MAX_ROW - band_height[2])) && col >= 21 && col <= 27 &&
band_num <= 2) {
band_matrix[row][col] = YELLOW;
}
if ((row >= (MAX_ROW - band_height[3])) && col >= 28 && col <= 34 &&
band_num <= 3) {
band_matrix[row][col] = BLUE;
}
if ((row >= (MAX_ROW - band_height[4])) && col >= 35 && col <= 41 &&
band_num <= 4) {
band_matrix[row][col] = PURPLE;
}
if ((row >= (MAX_ROW - band_height[5])) && col >= 42 && col <= 48 &&
band_num <= 5) {
band_matrix[row][col] = CYAN;
}
if ((row >= (MAX_ROW - band_height[6])) && col >= 49 && col <= 55 &&
band_num <= 6) {
band_matrix[row][col] = WHITE;
}
}
}

</source>

=='''MP3 Decoder'''==

The Audio Decoder breakout board communicates with the SJ board over SPI and is interfaced with the SPI-0 pins of the SJ board as follows:

*Clock Pin (Pin 13) - SJ SPI-0 Clock Pin
*MISO Pin (Pin 12) - SJ SPI-0 MISO Pin
*MOSI Pin (Pin 11) - SJ SPI-0 MOSI Pin
*MP3 CS: Chip Select Pin for the audio decoder to be activated while sending control signals.
*MP3 DCS: Chip Select Pin for the audio decoder to be activated while sending audio data signals.
*MP3 RST: Reset pin for the audio decoder.
*MP3 DREQ: Data Request Pin. Audio decoder signals that it is ready to accept next 32 bytes of audio data.
*VCC pin - SJ 3.3V pin
*GND pin - SJ GND Pin

=== Hardware Design ===
[[File:Slide1.png|800x900px|thumb|center|MP3 Decoder Pin Diagram]]

=== Software Design ===

[[File:Mp3_fLow.png|600x500px|thumb|center|MP3 Decoder Software Design]]

=== Implementation ===

We are interfacing MP3 Decoder on the SPI0 for reading the Audio Mp3 file from the SDCard and send Mp3 data to the Decoder. The purpose of this task is to send mp3 data to the mp3 decoder. This is a high priority as it is acting as a consumer. The producer task in our project is the task that reads songs that fill the freeRTOS queue with 4KB of data. The consumer task i.e the task that sends a song to the mp3 decoder that waits on an empty queue for portMAX_DELAY. Once the queue has data, the task starts sending 32 bytes at a time to the MP3 decoder. Once 32 bytes are sent, the task waits for the DREQ pin to get high. DREQ pin high indicates that the MP3 decoder unit is ready to take 32 bytes of data. For sending data, the task acquires the MUTEX so that no other task can use the SPI bus at the same time. Once the 32 bytes are sent, the MUTEX is released. This is the working of the task.

// Task to send data to decoder(High priority)
static uint8_t bytes_to_be_sent_to_decoder[READ_BYTES_FROM_FILE];
static uint8_t current_count = 0;
uint32_t start = 0, end = 0;
while (1) {
if (0 == current_count) {
xQueueReceive(mp3_queue, &bytes_to_be_sent_to_decoder[0], portMAX_DELAY);
}
start = (current_count * TRANSMIT_BYTES_TO_DECODER);
end = ((current_count + 1) * TRANSMIT_BYTES_TO_DECODER);
while (!mp3__dreq_get_status()) {
mp3__decoder_refresh();
vTaskDelay(2);
}
if (xSemaphoreTake(mp3_mutex, portMAX_DELAY)) {
mp3__data_cs();
send_32_bytes_to_decoder_using_ssp(start, end,
&bytes_to_be_sent_to_decoder[0]);
mp3__data_ds();
xSemaphoreGive(mp3_mutex);
if (current_count == COUNT - 1) {
current_count = start = end = 0;
} else {
current_count += 1;
}}}

=='''Audio Frequency Analyzer'''==

In the audio analyser, strobe and reset pins are used to select the DC peak output. Reset high resets the multiplexer. Reset low enables the strobe pin. At the leading edge of the first strobe, the first frequency band 63Hz is on the output. On each additional leading edge strobe the next frequency band(160Hz, 400Hz, 1kHz, 2.5kHz, 6.25kHz, 16kHz) is detected.

This analyser takes input from Audio decoder for left and right side music. SJ2 controls the RS and ST pins of the "Audio Frequency Analyzer" and reads input data from S pin which is connected to ADC pin (P0.26) of SJ2 board.

*Audio Analyzer S pin -> SJ2 ADC4 pin
*Audio Analyzer RS pin -> SJ2 P0.11 pin
*Audio Analyzer ST pin -> SJ2 P2.0 pin
*Audio Analyzer + pin -> SJ2 VCC pin
*Audio Analyzer - pin -> SJ2 GND pin
<div style="clear: both"></div>

====Audio Frequency Analyser====
Audio frequency analyser is working is most important task in order to get correct value. Incorrect initialisation and in efficient delays may cause error. In this project Init and reading of data at each frequncy band is implemented based on timing diagram shown as bellow:

[[File:244 Spark TimingDiagram AudioAnalyser.jpeg|thumb|550x400px|centre|Timing Diagram of Audio Analyser]]

The software Implementation to Init frequency analyser is as follow: 
1. Select ADC pin 
2. Select GPIO pin direction for reset pin and STOBE pin 
3. Reset Audio frequency analyser 

=='''Sensors Interface'''==

We have worked on two sensors for accessing our entertainment box i.e. Gesture Sensor and Accelerometer. The SJ-Two board has both sensors on board sensor which is interfaced on the I2C bus. Accelerometers are electromechanical devices that sense either static or dynamic forces of acceleration. Static forces include gravity, while dynamic forces can include vibrations and movement. The measurements are on 3-axis and these values can be calibrated to find the desired values.

In our project, an accelerometer is for controlling Controls in the MP3 Mode like PLAY,PAUSE,PLAY Next Song and Back to Previous Song.However in Game Mode we are playing our fruit fury game using Orientation sensor for Smashing fruits coming in Directions South East, South West ,North East and North West and We were using Gesture on SJ-Two Board for gesture recognitions Left, Right, UP and Down to change the configuration in MP3 Mode but after implementation we have realised that giving gesture is more complicated then getting signals from orientation.

=== Hardware Design ===

[[File:Sensor.png|800x900px|thumb|center|APDS9960 & MMA8452Q on board Sensors]]

=== Software Design ===

[[File:Sensor_FLow.png|600x500px|thumb|center|MMA8452Q Software Design]]

=== Implementation ===
The MMA8452Q has an orientation detection algorithm with the ability to detect all six orientations but we are using only 4 orientations i.e. Portrait Up, Portrait Down,Landscape Left and Landscape Right .The transition from portrait to landscape is fixed with a 45° threshold angle and a ±14° hysteresis angle. This allows the for a smooth transition from portrait to landscape at approximately 30° and then from landscape to portrait at approximately 60°.

[[File:accel_orient.png|800x900px|thumb|center|Portrait Orientation]]

We have used the following register settings to configure the sensors and getting all 4 directions and Orientation.

[[File:APDS_Register.png|800x900px|thumb|center|Registers of APDS9960]]

 

After reading the registers we are just performing the actions as per the Orientation detected.

[[File:Accel_register.png|800x900px|thumb|center|Registers of MMA8452Q]]

 

void perform_action_on_orientation(void *p)
{
orientation_e value;
while (1)
{
value = GetOrientation();
switch (value)
{
case Portrait_UP: // Prev Song
printf("Direction Left\n");
xSemaphoreGive(sem__prev_song);
break;
case Portrait_DOWN: // Next Song
printf("Direction Right\n");
xSemaphoreGive(sem__next_song);
break;
case Landscape_LEFT: // Resume/Play/
printf("Direction Up\n");
vTaskSuspend(handle__play_song);
vTaskSuspend(handle__freq_bands);
song_status = PLAY;
break;
case Landscape_RIGHT: // Pause/Stop/Volume Decrease
printf("Direction Down\n");
vTaskResume(handle__play_song);
vTaskResume(handle__freq_bands);
song_status = PAUSE;
break;
default:
break;
}
vTaskDelay(50);
}}

=='''Bluetooth Interface'''==
The SJ-two is connected to the Bluetooth module through the Serial interface (UART3) and we have configured it at 38400 baud rate with 8-bit data and 1 stop bit using the Communication Mode. It is used to send and receive the Game and Music data from our entertainment device to an android application.

=== Hardware Design ===

[[File:Slide3.png|700x900px|thumb|center|Bluetooth Interface Pin Diagram]]

===HC-05 Bluetooth module===
HC-05 Bluetooth Module is used to set up wireless communication between the entertainment device and the Android phone. The right section of the Bluetooth Board has connection pins for power and signals as well as a 5V to 3.3V Regulator, LED, and level shifting.

'''HC-05 PinOut'''
* EN: N/A
* VCC: 5V Power
* GND: Ground
* TXD: Serial Transmit pin connected to RXD3 of SJ board
* RXD: Serial Receive pin connected to TXD3 of SJ board
* STATE: States if connected or not

=== Software Design ===

[[File:Bluetooth_Sw_diagram.png|600x500px|thumb|center|Bluetooth Software Design]]

=== Implementation ===

An accelerometer is used in the MP3 Mode to implement functionalities such as play, pause, switch to next and previous songs and volume control. In the game mode the “Fruit fury” game is played by smashing fruits appearing in the directions South East, South West, North East and North West. UART3 is used as communication protocol.The Bluetooth commands that we are using to interact with Mobile app and Device are as follows:

GAMING = 0xA1,
NORTH_EAST = 0x71,
NORTH_WEST = 0x72,
SOUTH_WEST = 0x73,
SOUTH_EAST = 0x74,
MUSIC = 0xA2,
SONG_LIST = 0xA3,
NEXT_SONG = 0xC2,
TOGGLE_SONG = 0xC1,
PREV_SONG = 0xC0,
ACK = 0x00,
NACK = 0xFF,
VOL_INC = 0xB1,
VOL_DEC = 0xB0

=='''Mobile Application'''==

{|
|[[File:Modes.jpeg|230px|thumb|List Of Feature in the APP]]
|[[File:GAME.jpeg|230px|thumb|Game Mode]]
|[[File:Mp3_song.jpeg|230px|thumb|MP3 Mode]]
|[[File:SongList.jpeg|230px|thumb|List Of Songs in SD Card]]
|}

=== Software Design ===

The Android app has been built using the cross platform framework [https://flutter.dev/ Flutter]

The app is composed of 3 parts, '''Game Mode''', '''MP3 Mode''' and '''MP3 Song List'''. On the main screen we first connect to the bluetooth before establishing connection with any of the modes. The working of each mode is explained in each subsection below.

A few variables to note in advance
ACK = 0x00, sent when successful
NACK = 0xFF, sent incase there is any error

====1. Game Mode ====

Wireless communication with the Entertainment box communication over Bluetooth protocol. Android Application is created which provides an interface to exchange data and configure the device.To enter the Game Mode screen we first check if the Bluetooth Connection is established. We send in a one byte data 0xa1 over bluetooth to the SJ2 Board and get back the response "a1$ack/nack$##" We then enter the game mode which displays a joystick that can be oriented to a direction wherever the fruit appears on the LED matrix. The corresponding orientation value is then transmitted.If the fruit had appeared in any of the quadrant then will send data from BLE APP to SJTwo Board.

'''1.''' First Quadrant (North-East): 0x71 
'''2.''' Second Quadrant (North-West): 0x72 
'''3.''' Third Quadrant (South-West): 0x73 
'''4.''' Fourth Quadrant (South-East): 0x74 

====2. MP3 Mode ====

To enter the MP3 Mode screen we first check if the Bluetooth Connection is established similar to the Game Mode. We send in one byte of data 0xa2 over bluetooth to the SJ2 Board and get back the response "a2$ack/nack$volumeInfo$currentSong$isPlaying/isPaused$##" where isPlaying is 1 and isPaused is 0. These values are loaded into the MP3 Mode Screen as initial values for the current song playing. We can then see a screen where we can control the various aspects of playing songs i.e Playing and Pausing the song, Go to next song and and Go to the previous song. We can also control the volume remotely.Controlling each part of this interface is the same as sending a single byte of data over bluetooth to the SJ2 Board.

'''1.''' Playing and Pausing Song - We just toggle the state of the Song. We issue this command by sending 0xc1 which is the Toggle State command. 
'''2.''' Next Song and Previous Song - Command for the previous and next song is 0xC0 and 0xC2. 
'''3.''' Control Volume remotely - For volume we divide the percentage 100 percent in 16 parts. We can send the value between 0xb0 to 0xbf in increments of one step. This is parsed on the SJ2 Board and converted to an equivalent volume signal. 

====3. MP3 Song List ====
To get the list of MP3 Songs which are present in the SD card, we first check if the Bluetooth Connection is established similar to the Game Mode and MP3 Song mode. We send in one byte of data 0xa3 over bluetooth to the SJ2 Board and get back the response "a3$ack/nack$data$data$...$##". APIs that were designed to read song information and data by Audio Decoder, will be used for achieving this functionality.

=='''OLED Screen'''==

[[File:Oled_screen.jpeg|thumb|600x600px|center|Oled Screen Functionality]]

=== Software Design ===

The open source package [https://github.com/olikraus/u8g2 u8g2] has been used.
There are already ready made functions for various OLED Drivers. The indepth setup guide can be found [https://github.com/olikraus/u8g2/wiki/u8g2setupc here]

=== Implementation ===

The u8g2 library is a very robust library which means that this code can be extended for any microcontroller as long as the interface is written properly.

We needed to write 2 main functions, outlined below, i.e byte_cb and gpio_and_delay_cb using the function prototype `uint8_t u8x8_lpc_gpio_and_delay(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr)`.

Since the SJ2 Board is connected to the OLED Screen on the SPI1 Bus we also need to write the SPI1 driver, mainly a method to that sends data over SPI to the Slave device i.e the OLED Screen

=== Initializing the u8g2 for LPC4078 ===

<source lang="cpp">

// Created a file `u8g2_wrapper.h

static gpio_s dc;
static u8g2_t u8g2;

void u8g2_wrapper__init(gpio_s *dc_pin) {
u8g2_Setup_ssd1306_128x64_vcomh0_1(&u8g2, U8G2_R0, u8x8_byte_4wire_hw_spi, u8x8_lpc_gpio_and_delay);
u8g2_InitDisplay(&u8g2);
u8g2_SetPowerSave(&u8g2, 0);

dc.pin_number = dc_pin->pin_number;
dc.port_number = dc_pin->port_number;
}

u8g2_t *u8g2_wrapper__get_instance() { return &u8g2; }

uint8_t u8x8_lpc_gpio_and_delay(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr) {
switch (msg) {
case U8X8_MSG_GPIO_AND_DELAY_INIT:
delay__ms(1);
break;
case U8X8_MSG_DELAY_MILLI:
delay__ms(arg_int);
break;
case U8X8_MSG_GPIO_DC:
// DONE, Write to the GPIO_DC Pin
if (arg_int == 0) {
gpio__reset(dc);
} else {
gpio__set(dc);
}
break;
case U8X8_MSG_GPIO_RESET:
break;
}
return 1;
}

uint8_t u8x8_byte_4wire_hw_spi(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr) {
uint8_t *data;
switch (msg) {
case U8X8_MSG_BYTE_SEND:
data = (uint8_t *)arg_ptr;
while (arg_int > 0) {
ussp1__exchange_byte((uint8_t)*data);
data++;
arg_int--;
}
break;
case U8X8_MSG_BYTE_INIT:
break;
case U8X8_MSG_BYTE_SET_DC:
if (arg_int == 0) {
gpio__reset(dc);
} else {
gpio__set(dc);
}
break;
case U8X8_MSG_BYTE_START_TRANSFER:
break;
case U8X8_MSG_BYTE_END_TRANSFER:
break;
default:
return 0;
}
return 1;
}

</source>

=='''Technical Challenges'''==

1. '''RGB LED Matrix''' 

* Getting control of the matrix was challenging as it needs to follow specific sequence of pin enabling/disabling at appropriate timing.

* Setting right delays to avoid flickers and get smooth transitioning between frames by using delays or for loops.

* Fixing high CPU utilization by changing delay__us to vTaskDelay.

* Designing elements of the game (title screen and fruit objects) which required careful plotting of pixel data.

2. '''Audio Decoder''' 

* The CPU utilization for sending a song task was very high (80% +).
* In order to reduce the utilization, we gave the vTaskDelay(1) while waiting for the DREQ to be high. The high DREQ indicates that the decoder is ready to receive next 32 bytes of data. So meanwhile, when the DREQ pin is low, we made task to sleep for vTaskDelay(1). After doing this, we significantly reduced the CPU utilization to 15%. We tried with vTaskDelay(2) to get CPU utilization of 10%.
* We further tried to make the CPU utilization below 10%. This was really a tough challenge, and figured out that the actual SPI clock is 1Mhz which is too slow as SPI is meant to operate at much higher speed. We changed the clock rate of SPI to 12MHz but the song speed was too slow. We checked the datasheet of the Mp3 decoder and set the internal clock multiplier to 4.5x. This make the shield operate at high clock rates at 12.XX Mhz. So keeping this in mind we made the SPI speed to 12MHz which is safe. We successfully achieved CPU utilization of 5-6% which is very much in the acceptable range.

3. '''PCB Designing''' 

* We realized that using GPP for long term is not a good idea. Initially we spent time in debugging our hardware and later we have realized like we can’t take this for our final day.
* We did multiple reviews before ordering our final PCB as none of us did that earlier. We have faced issue in manual routing on Eagle Autodesk but our ISA Prashant helped us and he reviewed our PCB design twice.

4. '''Mobile Application''' 

* The main challenge of the Mobile application was to make the UI interactive while getting data asynchronously over the Bluetooth module.
* There was a global listener stream implemented that got the value and concatenate the string till we received the end frame (##).
* However the challenge still existed to know which screen has called what data which prompted us to create the key and ACK/NACK pair in the start.
* The Mobile app is completely data reactive, which means that the UI components render and change according to the data provided. This caused a lot of issues mainly since we tried polling methods to make sure that the UI remains up to date with the STATE of the SJ2 Board.
* A manual approach was opted for mainly to make the system more deterministic and for better debugging capabilities.

=='''Suggestions for Future Students'''==
 '''RGB LED Matrix''' 

* To begin with, focus on writing a simple driver to get control of 1 pixel at a targeted location and then use appropriate loops to light up the entire row/column.

* Make sure all pixels are able to light up with all possible colors to eliminate hardware defects.

* Try with minimum / no delays, print tick counts and then come up with meaningful delay numbers.

* Optimize the code (minimum delays, avoiding repetitive function calls, etc.) to bring down the CPU usage level.

* Use the link in the references to draw desired elements and generate the matrix.

 '''Tips for getting GOOD Grades and to remain in top 3 teams''' 
* Select your teammates wisely, and make sure every one dedicates themself for this project.
* Be an active member of your team and review rubrics for the final DEMO.
* As soon as the professor mentions the project, please start working on the project otherwise, in the end, you have to struggle with finals and you will be left with less time for testing and you have to struggle in demo.

 '''General tips''' 
* Remember the KISS approach when you code. (Keep It Simple and Stupid).
* For this project, one should know the basics in C/ C++, FreeRTOS, and some good debugging skills. Because if you don't have one, you will eventually end up spending more time debugging your problem.
* Always give meaningful names to the variable or the function, so a third person reviewing the code gets an overall idea by just reading the name.

=='''Conclusion'''==
It was a really great working experience for all of us. We were really thrilled from the beginning that we will be working on something that is quite relevant in the industries. We worked as a team of four which helped us all to know the importance of team-work and co-ordination. We learned many great stuff like

* State Design using FreeRTOS
* FreeRTOS APIS when task handles are NULL vs when Initialised.
* Uses of extern and global variables as opposed to encapsulation i.e static inside private 'c' files.
* Learning Optimization through the integration of our peer's individual modules
* Improving CPU utilisation of the main LED and MP3 tasks.
* Workload sharing and cooperation amongst peers.
* Sharing ideas and debugging a common problem together i.e team building.
* We realised that using GPP for long term is not a good idea, there were some breakdown in the wires and our MP3 stopped working. Initially we spent a lot of time debugging hardware and doing soldering. So we started designing the PCB, and when our PCB was done, we spent hardly any time debugging the hardware.
* Git : We learnt all the basic of GIT and it plays an important to role for source code versioning.

There were a lot of problems while doing this project but it was a steep learning curve. In the end we were able to achieve our objective with really good results.

=='''Project Video'''==
https://youtu.be/vVjHCoyWYz4

=='''Project Source Code'''==
* Git Project Link (Individual Modules): [https://gitlab.com/Infinity_Mirror/infinity_mirror-cmpe-244]
* Git Project Link: [https://gitlab.com/ganeshram2493/infi_mirror]

=='''Project Presentation File'''==
* [https://drive.google.com/file/d/1Q_Xvs-a2feQcr-FbPEKbwmlhi35hqNxX/view?usp=sharing Presentation Link]

=='''References'''==
=== Acknowledgement ===

We would like to express our gratitude to Professor Preetpal Kang for generously sharing his time and knowledge with us and guiding us through the completion of this project. We would also like to thank the Prashant Gandhi(ISA) for their valuable advice and constructive feedback.

=== References Used ===

====== Flutter Android GUI ======
* [https://material.io/resources/icons/?style=baseline Material Design Icons]
* [https://flutter.dev/ Building a Dynamic UI with Flutter]
* [https://www.youtube.com/channel/UCwXdFgeE9KYzlDdR7TG9cMw Flutter Youtube Channel]

====== RGB LED Matrix Interfacing and Designing ======
* [https://www.sparkfun.com/products/14718 Datasheet and Hookup guide]
* [https://cdn-learn.adafruit.com/downloads/pdf/32x16-32x32-rgb-led-matrix.pdf?timestamp=1543806512/ Wiring and pin information]
* [https://www.riyas.org/2013/12/online-led-matrix-font-generator-with.html Hex code generator to build LED matrix models]

====== MP3 Decoder and Frequency Analyzer ======
* [https://www.sparkfun.com/datasheets/Components/General/MSGEQ7.pdf Seven Band Graphic Equalizer MSGEQ7 Data Sheet]
* [https://www.kr4.us/SparkFun-MP3-Player-Shield.html?gclid=EAIaIQobChMIov3f7PWc2wIVDtVkCh0-rgStEAYYASABEgIEgPD_BwE SparkFun-MP3-Player-Shield Datasheet]

====== Gesture & Orientation Sensors ======
* [https://cdn.sparkfun.com/assets/learn_tutorials/3/2/1/Avago-APDS-9960-datasheet.pdf Gesture Sensor Data Sheet]
* [https://learn.sparkfun.com/tutorials/mma8452q-accelerometer-breakout-hookup-guide/all Accelerometer Sensor Data]

====== General/Miscellaneous ======
* [http://socialledge.com/sjsu/index.php/FreeRTOS_Tutorial FreeRTOS Tutorial]
* [https://sjsu-dev2.readthedocs.io/en/latest/?badge=latest SJTwo-c Documentation]

F19: Infinity Mirror

2019-12-18T23:46:24Z

Proj user22: /* RGB LED Matrix */

== '''Abstract''' ==

The main theme of the project is to build an interactive embedded system consisting of two entertainment modes - Music and Gaming. On the music mode, the MP3 decoder module reads songs from an SD card on the MCU board and plays the music through a speaker. It deals with the convergence of various services such as playing a game with background music, control volume, switch and pause/play songs. While the song is being played, audio frequency spectrum bands based on music tune are displayed on the LED Matrix band visualization etc. On the game mode, a fruit smashing game called “Fruit Fury” is implemented where the user needs to orient the MCU board in a direction according to where the fruit appears on the LED matrix. Alongside, the user can listen and switch songs. To achieve the above functionalities, various elements such as Audio Decoder, Audio frequency analyzer, 32x64 RGB LED Matrix and HC-05 bluetooth module and Android application are integrated.

[[File:High_level1.png|800px|thumb|center|Block Diagram of Infinity Mirror]]

== '''Introduction & Objectives''' ==

The key features supported by the system is real-time orientation recognition & trigger respective actions in 2 modes - MP3 mode and Game mode.

MP3 MODE:

1. Determine the accelerometer sensor values based on the orientation of the board and perform music control such as play, pause, volume control and changing songs.

2. In response, retrieve the data from the SD Card & communicate to the audio decoder for appropriate audio streaming.

3. Also implemented interaction with HC-05 bluetooth module through a customized mobile application and provide same operations.

4. Display frequency spectrum bands in sync to the tune of the song played.

[[File:frequency_bands.png|800px|thumb|center|Frequency bands]]

GAME MODE - Fruit Fury:

1. Determine the accelerometer sensor values based on the orientation of the board and hit the fruit in corresponding direction.

2. Incorporating provision on the board's switches to change to next or previous song.

3. Also implemented interaction with HC-05 bluetooth module through a customized mobile application and play the game through the same.

[[File:Title Screen.jpeg|800px|thumb|center|Title Screen]]

'''Project Objectives'''
'''1. Audio Decoder''' - Fetches song data from the SD card and plays it over a speaker.
'''2. RGB LED Matrix''' - Display frequency bands on music mode or view the game on game mode.
'''3. Audio Frequency Analyzer''' - To convert the audio data into 7 spectrum bands which is then displayed as individual colored bands on the LED matrix.
'''4. Bluetooth HC-05''' - Interfaces the system using Bluetooth to an Android application.

'''Team Objectives'''
'''1.''' Learn each and every module as much as possible, in order to develop an overall product.
'''2.''' Understand the proper use of queues and semaphores in order to send/receive the data between multiple tasks.
'''3.''' Learn to integrate all modules and ensuring smooth transition, communication and context switching at desired time intervals.
'''4.''' Document and track all the bugs encountered during development and learn to update git repository after every fix.

== '''Team Members & Technical Responsibilities''' ==
[[File:cmpe244_F19_Infinity_Mirror_members.jpeg|thumb|500x500px|TEAM INFINITY MIRROR|right]]

*'''''[http://linkedin.com/in/aakash-chitroda-17841740 Aakash Chitroda]'''''
** MP3 Audio Encoder/Decoder
** Audio frequency Analyzer logic

*'''''[https://www.linkedin.com/in/ganeshram93 Ganesh Ram]'''''
** Interfacing of LED Matrix and driver design
** Game logic design
** Audio frequency spectrum logic on LED
** Packaging

*'''''[https://www.linkedin.com/in/niket-naidu-30090a134/ Niket Naidu]'''''
** Android & Bluetooth Application
** OLED Interfacing and Designing
** PCB Design improvements
** Accelerometer Sensor integration with OLED Screen

*'''''[https://www.linkedin.com/in/vidushi-jain-048b992a Vidushi Jain]'''''
** Bluetooth Communication
** Interfacing of Gesture & Accelerometer Sensors
** Hardware Designing & PCB Integration

 

== '''Administrative Responsibilities''' ==
{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|- style="vertical-align: top;"
! colspan="5" style="background:#588ecc" | Administrative Roles 
|-
! style="text-align: left;" |
* Team Lead 
| Aakash Chitroda 
|-
! style="text-align: left;" |
* Finance Manager
| Niket Naidu 
|-
! style="text-align: left;" |
* Git Repository Manager 
| Vidushi Jain 
|-
! style="text-align: left;" |
* Wiki Report Manager 
| Vidushi Jain 
 Ganesh Ram 
|-
! style="text-align: left;" |
* Bill of Materials Manager 
| Ganesh Ram 
|}

== '''Team Deliverables Schedule''' ==

{| class="wikitable"
|-
! scope="col" style="text-align: left;" style="background:#588ecc;" | WEEK
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
START DATE 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
END DATE 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
TASK DETAILS 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
STATUS 
|-
| 1 || 15 Oct 2019 || 22 Oct 2019 ||
*Create and establish GitLab repository
*Establish slack channel and invite Preet
*Look through previous years projects and study it
*Distribute major roles among team members
|| Completed Completed Completed Completed 
|-
| 2 || 23 Oct 2019 || 29 Oct 2019 ||
* Create a Bill of Materials 
* Select and order Parts 
* Review Data-sheet and Interfacing Of LED Matrix(Ganesh) 
* Review Data-sheet for Gesture sensor(Vidushi) 
* Make Repo on Gitlab for all modules - Follow Naming Convention. 
|| Completed Completed Completed Completed Completed 
|-
| 3 || 30 Oct 2019 || 5 Nov 2019 ||
* Review Data-sheet of Audio MP3 shield(Aakash) 
* Start Soldering for LED matrix and MP3 Shield 
* Start Soldering of Headers for MP3 Shield & decoder
* Environmental setup of Android & Web applications(Niket) 
* Implementation of Gesture Detection (Vidushi)
* Implementation of displaying text and basic shapes on LED Matrix (Ganesh)
|| Completed Completed Completed Completed Completed Completed 
|-
| 4 || 6 Nov 2019 || 12 Nov 2019 ||
* Implementation of OLED Driver(Niket)
* Initialization the Audio Decoder through SPI communication and read manufacturer ID 
* Implementation of random frequency bands on LED matrix (Ganesh)
* Implementation of communication Between two task(gesture_detect & LED_Display) using queues and semaphores (Vidushi)
* Display Gesture Sensor Directions on OLED in a Text (Vidushi & Niket)
* Read Song from SD Card 
|| Completed Completed Completed Completed Completed Completed 
|-
| 5 || 13 Nov 2019 || 19 Nov 2019 ||
* Circuit Simulation in Diptrace/Eagle Tool. 
* PCB Layout Design in Diptrace/Eagle Tool. 
* Finalize Components placement on PCB. 
* Read Song from SD Card and send to MP3 Shield 
* Receive Values from audio spectrum and send to display task to display on LED Matrix.(Aakash & Ganesh) 
* Interface OLED with onboard buttons to access the list of songs (Niket)
* Developing logic for the ball movement and translating hand-gesture control into LED movement.(Ganesh)
|| Completed Completed Completed Completed Completed Completed Completed 
|-
| 6 || 20 Nov 2019 || 26 Nov 2019 ||
* Interfacing of all modules sensors, bluetooth , MP3 and LED Matrix
* Test whole implementation after integration of all modules
* Test for stack overflow and system crash
* Debug and Test the Play/Pause/Stop functionality of MP3 player 
* Integrate fruit Fury game logic
* Update Final Wiki Schedule. 
|| Completed Completed Completed Completed Completed Completed Completed 
|-
| 8 || 27 Nov 2019 || 3 Dec 2019 ||
* Additional Feature week
* Establish Bluetooth communication of Device and Mobile APP 
* Develop UI on Android application. 
* Add Play/Pause/Stop and Song selection functionality to the APP. 
* Update Wiki with new details and information. 
* Enhanced game logic and integrated song play feature in game 
|| Completed Completed Completed Completed Completed 
|-
| 9 || 4 Dec 2019 || 10 Dec 2019 ||
* TESTING - CRITICAL WEEK 
* Packaging of hardware board and related components. 
* Check overall robustness of the complete system. 
* Establish complete connection on PCB 
* Update wiki with details. 
|| Completed Completed Completed Completed Completed 
|-
| 10 || 11 Dec 2019 || 17 Dec 2019 ||
* All hands on testing and final bug fixes. 
* Check for tuning or calibration of sensors if required. 
* Complete end-to-end testing for various scenarios and conditions. 
* Create the semester long project activity video and upload to YouTube. 
* Update and finalize wiki. 
|| Completed Completed Completed Completed Completed 
|-
| 11 || 18 Dec 2019 || ||
* '''DEMO: Final Project''' 
* '''SUBMISSION: Final Project Wiki''' 
|| Completed Completed 
|}

== '''Bill of Materials (General Parts)''' ==

{| class="wikitable"
|-
! scope="col" style="text-align: left;" style="background:#588ecc;" | PART NAME 

! scope="col" style="text-align: left;" style="background:#588ecc;" | 
PART MODEL & SOURCE 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
QUANTITY 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
COST PER UNIT (USD) 
|-
|
* Micro-Controller Eval-Boards
|
* LPC 4078 (Purchased from Preet Kang)
|
* 1
|
* 50.00

|-
|
* Audio decoder Breakout Board
|
* [https://www.sparkfun.com/products/12660 SparkFun MP3 Player Shield]
|
* 1
|
* 26.95

|-
|
* Audio Analyzer
|
* [https://www.amazon.com/dp/B074T9H8JV/ DFR0126 Audio Analyzer]
|
* 1
|
* 19.00

|-
|
* RGB LED matrix
|
* [https://www.sparkfun.com/products/14718 32 x 64 RGB LED Matrix Panel]
|
* 1
|
* 49.95

|-
|
* Power supply
|
* [https://www.sparkfun.com/products/15352 5V / 4A Power Supply]
|
* 1
|
* 12.95

|-
|
* Audio Speakers
|
* 3.5mm Jack Stereo Speakers
|
* 1
|
* Own

|-
|
* PCB parts and other Miscellaneous parts
|
* Anchor Electronics and Digikey '''
|
* 1
|
* 50.00

|-
|
* 2 way mirror
|
* [https://www.amazon.com/gp/product/B06Y2C79FC/ref=ppx_yo_dt_b_asin_title_o03_s00?ie=UTF8&psc=1 2-way mirror ]
|
* 1
|
* 7.64

|-
|
* PCB Fabrication
|
* [https://jlcpcb.com/quote JLCPCB]
|
* 5
|
* 29.53
|}

 

== '''Printed Circuit Board''' ==

=== Design And Architecture ===

We have designed the custom PCB using Eagle Software and as well as one prototype board in which we have connected all the modules with SJ-Two board. PCB was sent to fabrication to JLCPCB China which provided PCB with lead time of 1 week. We have implemented 2 layers of PCB with all of the parts in top layer.

'''Components Placements on PCB and on Prototype Board'''
'''1.''' One SJ-Two board is fitted onto the top of the 3D printed lid cover which with a slot opening for 2x40 IDC cable.
'''2.''' MP3 Decoder is connected with SJ-Two board and will be place on the right side of PCB and as well as on Prototype board.
'''3.''' Bluetooth Module needs only 4 pins to connect with SJ-Two and goes to UART3 and placed on the top left of the board.
'''4.''' LED Matrix is connected using 2x8 IDC cable pins on the top left side of the board.
'''5.''' Audio Frequency Analyzer is placed on the bottom side of PCB.
'''6.''' Power supply of 5v and 3.3v provisions are made on the bottom left side of PCB.

{|
[[File:Top_Layout.png|500x600px|thumb|left|Top Layer PCB Design On Eagle Software]]
|[[File:Bottom_Layout.png|500x600px|thumb|right|Bottom Layer PCB Design on Eagle Software]]
|}

{|
[[File:Top_View.png|500x600px|thumb|left|PCB Top Layer]]
|[[File:Bottom_View.png|500x600px|thumb|right|PCB Bottom Layer]]
|}

'''Infinity Mirror's Internal Circuit'''

[[File:Setup.jpeg|thumb|350x350px|center|Infinity Mirror: Internal Circuit of Embedded Entertainment Box]]

=='''Product Enclosure''' ==

To facilitate easy and convenient gaming experience and also act as an effective audio controller, a single 3D printed enclosure was designed which is spacious enough to accommodate the MCU modules like bluetooth, audio frequency analyzer and MP3 decoder on the PCB.

{|
|[[File:Top.jpeg|470px|thumb|left|Top View]]
|[[File:3D.png|430px|thumb|right|3D View]]
|}

===Final 3D Package===
[[File:Final_Setup.jpeg|thumb|600x600px|center|Infinity Mirror: Final Setup]]

=='''RGB LED Matrix'''==
A 32 x 64 RGB LED Matrix will be powered up through a 5V/4A DC adapter and is interfaced with the board to play the game 'Fruit Fury' with desired background song in the game-mode and to display the frequency bands and other relevant messages such as "Next", "Previous" and "Pause" in the music-mode. Only the INPUT IDC connector will be used because we are not cascading multiple matrices. The matrix has 2 planes (upper and lower), both of which will be programmed separately. In order to set RGB color data for each pixel in plane 1 (top half of the display) we use R1, G1 and B1 pins and for plane 2 we use R2, G2 and B2. By setting and resetting the CLOCK pulse, color data is set for every pixel in the row. Then the LATCH is set to mark end of the row and reset to move to next row. All of these steps are repeated at very less time intervals so that the human eye perceives it as one complete frame (Persistence of Vision).

Below is the description of the pins:
== Pin Configuration ==
{| class="wikitable"
|-
! scope="col"| Pin
! scope="col"| Pin Desciption
|-
! scope="row"| R1
| Sets upper panel's Red data
|-
! scope="row"| G1
| Sets upper panel's Green data
|-
! scope="row"| B1
| Sets upper panel's Blue data
|-
! scope="row"| R2
| Sets lower panel's Red data
|-
! scope="row"| G2
| Sets lower panel's Green data
|-
! scope="row"| B2
| Sets lower panel's Blue data
|-
! scope="row"| A
| Sets row bit 0
|-
! scope="row"| B
| Sets row bit 1
|-
! scope="row"| C
| Sets row bit 2
|-
! scope="row"| D
| Sets row bit 3
|-
! scope="row"| E
| Sets row bit 0
|-
! scope="row"| nOE
| Set to switch the LEDs off when transitioning from one row to the next
|-
! scope="row"| LATCH
| Set to mark completion of one row
|-
! scope="row"| CLK
| Set to access each pixel
|-
! scope="row"| GND
| Ground pins to be connected with board's GND.
|-
|}

Below are the technical specifications:

*Pitch -> 4 mm
*Resolution -> 32 x 64 = 2048 dots
*Panel dimensions (l x b x h) in mm -> 256 x 128 x 13
*Working voltage/current rating -> 5v / 4A (max)
*Scan rate - 1/16
*Pixel component configuration (R,G,B) -> 1,1,1
*Weight -> 0.24 kg

=== Hardware Design ===
The hardware involves 5V/4A DC power supply adapter, barrel jack connectors and IDC cables to power up the LED matrix and communicate with the board. Below is the pin interfacing diagram.
[[File:Slide2.png|700x900px|thumb|center|LED Matrix Pin Diagram]]

=== Software Design ===
1. '''Fruit Fury - Game mode''' 

There are 2 tasks involved to ensure functioning of the game.

a) Task 1:
*Display the game's title screen. On pressing the onboard switch (SW1), game begins.
*Also used to display game over screen / win screen.
b) Task 2:
*Enter into game mode to play the game.
*Read accelerometer values (board orientation) and render game frame.
*Detect the player's board movement, compare it with fruit's location.
*Display score, lives and smash effects.
*Press another switch (SW0) to stop game and return to title screen or to restart the game once it is over.

 '''Game rules:''' 

a) Game comprises of 3 levels (level 2 on reaching score 15 and level 3 on reaching score 30) and 5 lives in total.

b) Primary objective is to tilt the board to the direction (North West, North East, South West or South East) in which the fruit appears in order to smash it.

c) Score increases by 1 point for smashing each fruit.

d) Bombs start appearing after completion of level 1, which costs a life when hit.

e) Level 3 is faster so make sure you tune your reflexes up.

f) Reach score 50 to win the game.

 '''Bonus:''' 

a) Streaks are rewarding. Smash 10 fruits straight up to win an extra life.

b) Look out for star fruits. Hit them to gain +2 points.

Choose your song to take all the inspiration you can and start smashing!

 '''2. Music mode''' 

a) Press the button to enjoy music-only mode. Graceful audio spectrum bands are displayed that dance to the tune of the chosen song.

b) A display is prompted to the user whenever music is paused or changed to next or previous song.

=== Implementation ===
'''LED Driver'''

1. Initialize the LED matrix by configuring necessary pin directions.

2. Disable Output Enable (OE) GPIO before feeding matrix data.

3. Select the required row by setting bits on A, B, C, D GPIO pins.

4. Loop through the pixels (columns) in the selected row and set the pixel color on R, G, B GPIO pins.

5. Set zero on R, G, B GPIO pins to mask that particular pixel.

6. Set and Reset the clock for pushing the R, G, B bits for each column.

7. Issue latch to mark the row's completion and reset latch before going to next row.

8. Follow the steps 2 to 7 for other rows.

<source lang="cpp">
for (uint8_t row = 0; row < (MAX_ROW / 2); row++) {
disableOE();
set_row(row);
for (uint8_t col = 0; col < MAX_COL; col++) {
LPC_GPIO0->PIN |= (1 << CLK);
set_color_bottom(game_matrix[row + (MAX_ROW / 2)][col]);
set_color_top(game_matrix[row][col]);
LPC_GPIO0->PIN &= ~(1 << CLK);
}
LPC_GPIO0->PIN |= (1 << LAT);
LPC_GPIO0->PIN &= ~(1 << LAT);
enableOE();
vTaskDelay(1);
}
</source>

'''Fruit Fury - Game mode'''

1. Generate the fruit's initial coordinate using random function (used srand() with time value as seed to get random pattern sets).

2. Construct the LED matrix array by drawing the fruit and borders.

3. Push the entire matrix data to LED driver to display the constructed matrix frame.

4. Then read the player's orientation and match with fruit's direction.

5. Modify game parameters (score, lives and level) based on player's results.

6. Stop game if all lives are over and display game over screen by switching to game init task (Task 1).

<source lang="cpp">
/* Push button to exit game */
if (LPC_GPIO0->PIN & (1 << SW0))
is_start_game = false;

if (is_start_game == true) {
/* Generate fruit's initial coordinate position */
get_fruit_begin_coord(&row_pt, &col_pt, &quadrant);
/* Generate final frame by considering fruit object at that position */
construct_game_matrix(row_pt, col_pt);
/* Draw final frame matrix of the game */
draw_final_game_frame();
/* Get the board direction from the user and increment score count */
compute_game_params(row_pt, col_pt, quadrant);
} else
vTaskResume(display_game_init_screen_t);
</source>

'''Spectrum display - Music mode'''

1. Read the audio frequency values from the graphic equalizer task and store it as an array.

2. Based on value of each frequency band, assign a height of the band (in pixels) to be drawn on the LED matrix.

3. Set a unique color for each band.

3. Push the entire matrix data to LED driver to display the constructed matrix frame.

4. Repeat steps 1 to 3 at required intervals to display repeating bands.

<source lang="cpp">

for (row = MAX_ROW - 1; row >= 1; row--) {
for (col = 7; col <= 62; col++) {
if ((row >= (MAX_ROW - band_height[0])) && col >= 7 && col <= 13 &&
band_num <= 0) {
band_matrix[row][col] = RED;
}
if ((row >= (MAX_ROW - band_height[1])) && col >= 14 && col <= 20 &&
band_num <= 1) {
band_matrix[row][col] = GREEN;
}
if ((row >= (MAX_ROW - band_height[2])) && col >= 21 && col <= 27 &&
band_num <= 2) {
band_matrix[row][col] = YELLOW;
}
if ((row >= (MAX_ROW - band_height[3])) && col >= 28 && col <= 34 &&
band_num <= 3) {
band_matrix[row][col] = BLUE;
}
if ((row >= (MAX_ROW - band_height[4])) && col >= 35 && col <= 41 &&
band_num <= 4) {
band_matrix[row][col] = PURPLE;
}
if ((row >= (MAX_ROW - band_height[5])) && col >= 42 && col <= 48 &&
band_num <= 5) {
band_matrix[row][col] = CYAN;
}
if ((row >= (MAX_ROW - band_height[6])) && col >= 49 && col <= 55 &&
band_num <= 6) {
band_matrix[row][col] = WHITE;
}
}
}

</source>

=='''MP3 Decoder'''==

The Audio Decoder breakout board communicates with the SJ board over SPI and is interfaced with the SPI-0 pins of the SJ board as follows:

*Clock Pin (Pin 13) - SJ SPI-0 Clock Pin
*MISO Pin (Pin 12) - SJ SPI-0 MISO Pin
*MOSI Pin (Pin 11) - SJ SPI-0 MOSI Pin
*MP3 CS: Chip Select Pin for the audio decoder to be activated while sending control signals.
*MP3 DCS: Chip Select Pin for the audio decoder to be activated while sending audio data signals.
*MP3 RST: Reset pin for the audio decoder.
*MP3 DREQ: Data Request Pin. Audio decoder signals that it is ready to accept next 32 bytes of audio data.
*VCC pin - SJ 3.3V pin
*GND pin - SJ GND Pin

=== Hardware Design ===
[[File:Slide1.png|800x900px|thumb|center|MP3 Decoder Pin Diagram]]

=== Software Design ===

[[File:Mp3_fLow.png|600x500px|thumb|center|MP3 Decoder Software Design]]

=== Implementation ===

We are interfacing MP3 Decoder on the SPI0 for reading the Audio Mp3 file from the SDCard and send Mp3 data to the Decoder. The purpose of this task is to send mp3 data to the mp3 decoder. This is a high priority as it is acting as a consumer. The producer task in our project is the task that reads songs that fill the freeRTOS queue with 4KB of data. The consumer task i.e the task that sends a song to the mp3 decoder that waits on an empty queue for portMAX_DELAY. Once the queue has data, the task starts sending 32 bytes at a time to the MP3 decoder. Once 32 bytes are sent, the task waits for the DREQ pin to get high. DREQ pin high indicates that the MP3 decoder unit is ready to take 32 bytes of data. For sending data, the task acquires the MUTEX so that no other task can use the SPI bus at the same time. Once the 32 bytes are sent, the MUTEX is released. This is the working of the task.

// Task to send data to decoder(High priority)
static uint8_t bytes_to_be_sent_to_decoder[READ_BYTES_FROM_FILE];
static uint8_t current_count = 0;
uint32_t start = 0, end = 0;
while (1) {
if (0 == current_count) {
xQueueReceive(mp3_queue, &bytes_to_be_sent_to_decoder[0], portMAX_DELAY);
}
start = (current_count * TRANSMIT_BYTES_TO_DECODER);
end = ((current_count + 1) * TRANSMIT_BYTES_TO_DECODER);
while (!mp3__dreq_get_status()) {
mp3__decoder_refresh();
vTaskDelay(2);
}
if (xSemaphoreTake(mp3_mutex, portMAX_DELAY)) {
mp3__data_cs();
send_32_bytes_to_decoder_using_ssp(start, end,
&bytes_to_be_sent_to_decoder[0]);
mp3__data_ds();
xSemaphoreGive(mp3_mutex);
if (current_count == COUNT - 1) {
current_count = start = end = 0;
} else {
current_count += 1;
}}}

=='''Audio Frequency Analyzer'''==

In the audio analyser, strobe and reset pins are used to select the DC peak output. Reset high resets the multiplexer. Reset low enables the strobe pin. At the leading edge of the first strobe, the first frequency band 63Hz is on the output. On each additional leading edge strobe the next frequency band(160Hz, 400Hz, 1kHz, 2.5kHz, 6.25kHz, 16kHz) is detected.

This analyser takes input from Audio decoder for left and right side music. SJ2 controls the RS and ST pins of the "Audio Frequency Analyzer" and reads input data from S pin which is connected to ADC pin (P0.26) of SJ2 board.

*Audio Analyzer S pin -> SJ2 ADC4 pin
*Audio Analyzer RS pin -> SJ2 P0.11 pin
*Audio Analyzer ST pin -> SJ2 P2.0 pin
*Audio Analyzer + pin -> SJ2 VCC pin
*Audio Analyzer - pin -> SJ2 GND pin
<div style="clear: both"></div>

====Audio Frequency Analyser====
Audio frequency analyser is working is most important task in order to get correct value. Incorrect initialisation and in efficient delays may cause error. In this project Init and reading of data at each frequncy band is implemented based on timing diagram shown as bellow:

[[File:244 Spark TimingDiagram AudioAnalyser.jpeg|thumb|550x400px|centre|Timing Diagram of Audio Analyser]]

The software Implementation to Init frequency analyser is as follow: 
1. Select ADC pin 
2. Select GPIO pin direction for reset pin and STOBE pin 
3. Reset Audio frequency analyser 

=='''Sensors Interface'''==

We have worked on two sensors for accessing our entertainment box i.e. Gesture Sensor and Accelerometer. The SJ-Two board has both sensors on board sensor which is interfaced on the I2C bus. Accelerometers are electromechanical devices that sense either static or dynamic forces of acceleration. Static forces include gravity, while dynamic forces can include vibrations and movement. The measurements are on 3-axis and these values can be calibrated to find the desired values.

In our project, an accelerometer is for controlling Controls in the MP3 Mode like PLAY,PAUSE,PLAY Next Song and Back to Previous Song.However in Game Mode we are playing our fruit fury game using Orientation sensor for Smashing fruits coming in Directions South East, South West ,North East and North West and We were using Gesture on SJ-Two Board for gesture recognitions Left, Right, UP and Down to change the configuration in MP3 Mode but after implementation we have realised that giving gesture is more complicated then getting signals from orientation.

=== Hardware Design ===

[[File:Sensor.png|800x900px|thumb|center|APDS9960 & MMA8452Q on board Sensors]]

=== Software Design ===

[[File:Sensor_FLow.png|600x500px|thumb|center|MMA8452Q Software Design]]

=== Implementation ===
The MMA8452Q has an orientation detection algorithm with the ability to detect all six orientations but we are using only 4 orientations i.e. Portrait Up, Portrait Down,Landscape Left and Landscape Right .The transition from portrait to landscape is fixed with a 45° threshold angle and a ±14° hysteresis angle. This allows the for a smooth transition from portrait to landscape at approximately 30° and then from landscape to portrait at approximately 60°.

[[File:accel_orient.png|800x900px|thumb|center|Portrait Orientation]]

We have used the following register settings to configure the sensors and getting all 4 directions and Orientation.

[[File:APDS_Register.png|800x900px|thumb|center|Registers of APDS9960]]

 

After reading the registers we are just performing the actions as per the Orientation detected.

[[File:Accel_register.png|800x900px|thumb|center|Registers of MMA8452Q]]

 

void perform_action_on_orientation(void *p)
{
orientation_e value;
while (1)
{
value = GetOrientation();
switch (value)
{
case Portrait_UP: // Prev Song
printf("Direction Left\n");
xSemaphoreGive(sem__prev_song);
break;
case Portrait_DOWN: // Next Song
printf("Direction Right\n");
xSemaphoreGive(sem__next_song);
break;
case Landscape_LEFT: // Resume/Play/
printf("Direction Up\n");
vTaskSuspend(handle__play_song);
vTaskSuspend(handle__freq_bands);
song_status = PLAY;
break;
case Landscape_RIGHT: // Pause/Stop/Volume Decrease
printf("Direction Down\n");
vTaskResume(handle__play_song);
vTaskResume(handle__freq_bands);
song_status = PAUSE;
break;
default:
break;
}
vTaskDelay(50);
}}

=='''Bluetooth Interface'''==
The SJ-two is connected to the Bluetooth module through the Serial interface (UART3) and we have configured it at 38400 baud rate with 8-bit data and 1 stop bit using the Communication Mode. It is used to send and receive the Game and Music data from our entertainment device to an android application.

=== Hardware Design ===

[[File:Slide3.png|700x900px|thumb|center|Bluetooth Interface Pin Diagram]]

===HC-05 Bluetooth module===
HC-05 Bluetooth Module is used to set up wireless communication between the entertainment device and the Android phone. The right section of the Bluetooth Board has connection pins for power and signals as well as a 5V to 3.3V Regulator, LED, and level shifting.

'''HC-05 PinOut'''
* EN: N/A
* VCC: 5V Power
* GND: Ground
* TXD: Serial Transmit pin connected to RXD3 of SJ board
* RXD: Serial Receive pin connected to TXD3 of SJ board
* STATE: States if connected or not

=== Software Design ===

[[File:Bluetooth_Sw_diagram.png|600x500px|thumb|center|Bluetooth Software Design]]

=== Implementation ===

An accelerometer is used in the MP3 Mode to implement functionalities such as play, pause, switch to next and previous songs and volume control. In the game mode the “Fruit fury” game is played by smashing fruits appearing in the directions South East, South West, North East and North West. UART3 is used as communication protocol.The Bluetooth commands that we are using to interact with Mobile app and Device are as follows:

GAMING = 0xA1,
NORTH_EAST = 0x71,
NORTH_WEST = 0x72,
SOUTH_WEST = 0x73,
SOUTH_EAST = 0x74,
MUSIC = 0xA2,
SONG_LIST = 0xA3,
NEXT_SONG = 0xC2,
TOGGLE_SONG = 0xC1,
PREV_SONG = 0xC0,
ACK = 0x00,
NACK = 0xFF,
VOL_INC = 0xB1,
VOL_DEC = 0xB0

=='''Mobile Application'''==

{|
|[[File:Modes.jpeg|230px|thumb|List Of Feature in the APP]]
|[[File:GAME.jpeg|230px|thumb|Game Mode]]
|[[File:Mp3_song.jpeg|230px|thumb|MP3 Mode]]
|[[File:SongList.jpeg|230px|thumb|List Of Songs in SD Card]]
|}

=== Software Design ===

The Android app has been built using the cross platform framework [https://flutter.dev/ Flutter]

The app is composed of 3 parts, '''Game Mode''', '''MP3 Mode''' and '''MP3 Song List'''. On the main screen we first connect to the bluetooth before establishing connection with any of the modes. The working of each mode is explained in each subsection below.

A few variables to note in advance
ACK = 0x00, sent when successful
NACK = 0xFF, sent incase there is any error

====1. Game Mode ====

Wireless communication with the Entertainment box communication over Bluetooth protocol. Android Application is created which provides an interface to exchange data and configure the device.To enter the Game Mode screen we first check if the Bluetooth Connection is established. We send in a one byte data 0xa1 over bluetooth to the SJ2 Board and get back the response "a1$ack/nack$##" We then enter the game mode which displays a joystick that can be oriented to a direction wherever the fruit appears on the LED matrix. The corresponding orientation value is then transmitted.If the fruit had appeared in any of the quadrant then will send data from BLE APP to SJTwo Board.

'''1.''' First Quadrant (North-East): 0x71 
'''2.''' Second Quadrant (North-West): 0x72 
'''3.''' Third Quadrant (South-West): 0x73 
'''4.''' Fourth Quadrant (South-East): 0x74 

====2. MP3 Mode ====

To enter the MP3 Mode screen we first check if the Bluetooth Connection is established similar to the Game Mode. We send in one byte of data 0xa2 over bluetooth to the SJ2 Board and get back the response "a2$ack/nack$volumeInfo$currentSong$isPlaying/isPaused$##" where isPlaying is 1 and isPaused is 0. These values are loaded into the MP3 Mode Screen as initial values for the current song playing. We can then see a screen where we can control the various aspects of playing songs i.e Playing and Pausing the song, Go to next song and and Go to the previous song. We can also control the volume remotely.Controlling each part of this interface is the same as sending a single byte of data over bluetooth to the SJ2 Board.

'''1.''' Playing and Pausing Song - We just toggle the state of the Song. We issue this command by sending 0xc1 which is the Toggle State command. 
'''2.''' Next Song and Previous Song - Command for the previous and next song is 0xC0 and 0xC2. 
'''3.''' Control Volume remotely - For volume we divide the percentage 100 percent in 16 parts. We can send the value between 0xb0 to 0xbf in increments of one step. This is parsed on the SJ2 Board and converted to an equivalent volume signal. 

====3. MP3 Song List ====
To get the list of MP3 Songs which are present in the SD card, we first check if the Bluetooth Connection is established similar to the Game Mode and MP3 Song mode. We send in one byte of data 0xa3 over bluetooth to the SJ2 Board and get back the response "a3$ack/nack$data$data$...$##". APIs that were designed to read song information and data by Audio Decoder, will be used for achieving this functionality.

=='''OLED Screen'''==

[[File:Oled_screen.jpeg|thumb|600x600px|center|Oled Screen Functionality]]

=== Software Design ===

The open source package [https://github.com/olikraus/u8g2 u8g2] has been used.
There are already ready made functions for various OLED Drivers. The indepth setup guide can be found [https://github.com/olikraus/u8g2/wiki/u8g2setupc here]

=== Implementation ===

The u8g2 library is a very robust library which means that this code can be extended for any microcontroller as long as the interface is written properly.

We needed to write 2 main functions, outlined below, i.e byte_cb and gpio_and_delay_cb using the function prototype `uint8_t u8x8_lpc_gpio_and_delay(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr)`.

Since the SJ2 Board is connected to the OLED Screen on the SPI1 Bus we also need to write the SPI1 driver, mainly a method to that sends data over SPI to the Slave device i.e the OLED Screen

=== Initializing the u8g2 for LPC4078 ===

<source lang="cpp">

// Created a file `u8g2_wrapper.h

static gpio_s dc;
static u8g2_t u8g2;

void u8g2_wrapper__init(gpio_s *dc_pin) {
u8g2_Setup_ssd1306_128x64_vcomh0_1(&u8g2, U8G2_R0, u8x8_byte_4wire_hw_spi, u8x8_lpc_gpio_and_delay);
u8g2_InitDisplay(&u8g2);
u8g2_SetPowerSave(&u8g2, 0);

dc.pin_number = dc_pin->pin_number;
dc.port_number = dc_pin->port_number;
}

u8g2_t *u8g2_wrapper__get_instance() { return &u8g2; }

uint8_t u8x8_lpc_gpio_and_delay(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr) {
switch (msg) {
case U8X8_MSG_GPIO_AND_DELAY_INIT:
delay__ms(1);
break;
case U8X8_MSG_DELAY_MILLI:
delay__ms(arg_int);
break;
case U8X8_MSG_GPIO_DC:
// DONE, Write to the GPIO_DC Pin
if (arg_int == 0) {
gpio__reset(dc);
} else {
gpio__set(dc);
}
break;
case U8X8_MSG_GPIO_RESET:
break;
}
return 1;
}

uint8_t u8x8_byte_4wire_hw_spi(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr) {
uint8_t *data;
switch (msg) {
case U8X8_MSG_BYTE_SEND:
data = (uint8_t *)arg_ptr;
while (arg_int > 0) {
ussp1__exchange_byte((uint8_t)*data);
data++;
arg_int--;
}
break;
case U8X8_MSG_BYTE_INIT:
break;
case U8X8_MSG_BYTE_SET_DC:
if (arg_int == 0) {
gpio__reset(dc);
} else {
gpio__set(dc);
}
break;
case U8X8_MSG_BYTE_START_TRANSFER:
break;
case U8X8_MSG_BYTE_END_TRANSFER:
break;
default:
return 0;
}
return 1;
}

</source>

=='''Technical Challenges'''==

1. '''RGB LED Matrix''' 

* Getting control of the matrix was challenging as it needs to follow specific sequence of pin enabling/disabling at appropriate timing.

* Setting right delays to avoid flickers and get smooth transitioning between frames by using delays or for loops.

* Fixing high CPU utilization by changing delay__us to vTaskDelay.

* Designing elements of the game (title screen and fruit objects) which required careful plotting of pixel data.

2. '''Audio Decoder''' 

a) The CPU utilization for sending a song task was very high (80% +).
* In order to reduce the utilization, we gave the vTaskDelay(1) while waiting for the DREQ to be high. The high DREQ indicates that the decoder is ready to receive next 32 bytes of data. So meanwhile, when the DREQ pin is low, we made task to sleep for vTaskDelay(1). After doing this, we significantly reduced the CPU utilization to 15%. We tried with vTaskDelay(2) to get CPU utilization of 10%.
* We further tried to make the CPU utilization below 10%. This was really a tough challenge, and figured out that the actual SPI clock is 1Mhz which is too slow as SPI is meant to operate at much higher speed. We changed the clock rate of SPI to 12MHz but the song speed was too slow. We checked the datasheet of the Mp3 decoder and set the internal clock multiplier to 4.5x. This make the shield operate at high clock rates at 12.XX Mhz. So keeping this in mind we made the SPI speed to 12MHz which is safe. We successfully achieved CPU utilization of 5-6% which is very much in the acceptable range.

3. '''PCB Designing''' 

* We realized that using GPP for long term is not a good idea. Initially we spent time in debugging our hardware and later we have realized like we can’t take this for our final day.
* We did multiple reviews before ordering our final PCB as none of us did that earlier. We have faced issue in manual routing on Eagle Autodesk but our ISA Prashant helped us and he reviewed our PCB design twice.

4. '''Mobile Application''' 

* The main challenge of the Mobile application was to make the UI interactive while getting data asynchronously over the Bluetooth module.
* There was a global listener stream implemented that got the value and concatenate the string till we received the end frame (##).
* However the challenge still existed to know which screen has called what data which prompted us to create the key and ACK/NACK pair in the start.
* The Mobile app is completely data reactive, which means that the UI components render and change according to the data provided. This caused a lot of issues mainly since we tried polling methods to make sure that the UI remains up to date with the STATE of the SJ2 Board.
* A manual approach was opted for mainly to make the system more deterministic and for better debugging capabilities.

=='''Suggestions for Future Students'''==
 '''RGB LED Matrix''' 

* To begin with, focus on writing a simple driver to get control of 1 pixel at a targeted location and then use appropriate loops to light up the entire row/column.

* Make sure all pixels are able to light up with all possible colors to eliminate hardware defects.

* Try with minimum / no delays, print tick counts and then come up with meaningful delay numbers.

* Optimize the code (minimum delays, avoiding repetitive function calls, etc.) to bring down the CPU usage level.

* Use the link in the references to draw desired elements and generate the matrix.

 '''Tips for getting GOOD Grades and to remain in top 3 teams''' 
* Select your teammates wisely, and make sure every one dedicates themself for this project.
* Be an active member of your team and review rubrics for the final DEMO.
* As soon as the professor mentions the project, please start working on the project otherwise, in the end, you have to struggle with finals and you will be left with less time for testing and you have to struggle in demo.

 '''General tips''' 
* Remember the KISS approach when you code. (Keep It Simple and Stupid).
* For this project, one should know the basics in C/ C++, FreeRTOS, and some good debugging skills. Because if you don't have one, you will eventually end up spending more time debugging your problem.
* Always give meaningful names to the variable or the function, so a third person reviewing the code gets an overall idea by just reading the name.

=='''Conclusion'''==
It was a really great working experience for all of us. We were really thrilled from the beginning that we will be working on something that is quite relevant in the industries. We worked as a team of four which helped us all to know the importance of team-work and co-ordination. We learned many great stuff like

* State Design using FreeRTOS
* FreeRTOS APIS when task handles are NULL vs when Initialised.
* Uses of extern and global variables as opposed to encapsulation i.e static inside private 'c' files.
* Learning Optimization through the integration of our peer's individual modules
* Improving CPU utilisation of the main LED and MP3 tasks.
* Workload sharing and cooperation amongst peers.
* Sharing ideas and debugging a common problem together i.e team building.
* We realised that using GPP for long term is not a good idea, there were some breakdown in the wires and our MP3 stopped working. Initially we spent a lot of time debugging hardware and doing soldering. So we started designing the PCB, and when our PCB was done, we spent hardly any time debugging the hardware.
* Git : We learnt all the basic of GIT and it plays an important to role for source code versioning.

There were a lot of problems while doing this project but it was a steep learning curve. In the end we were able to achieve our objective with really good results.

=='''Project Video'''==
https://youtu.be/vVjHCoyWYz4

=='''Project Source Code'''==
* Git Project Link (Individual Modules): [https://gitlab.com/Infinity_Mirror/infinity_mirror-cmpe-244]
* Git Project Link: [https://gitlab.com/ganeshram2493/infi_mirror]

=='''Project Presentation File'''==
* [https://drive.google.com/file/d/1Q_Xvs-a2feQcr-FbPEKbwmlhi35hqNxX/view?usp=sharing Presentation Link]

=='''References'''==
=== Acknowledgement ===

We would like to express our gratitude to Professor Preetpal Kang for generously sharing his time and knowledge with us and guiding us through the completion of this project. We would also like to thank the Prashant Gandhi(ISA) for their valuable advice and constructive feedback.

=== References Used ===

====== Flutter Android GUI ======
* [https://material.io/resources/icons/?style=baseline Material Design Icons]
* [https://flutter.dev/ Building a Dynamic UI with Flutter]
* [https://www.youtube.com/channel/UCwXdFgeE9KYzlDdR7TG9cMw Flutter Youtube Channel]

====== RGB LED Matrix Interfacing and Designing ======
* [https://www.sparkfun.com/products/14718 Datasheet and Hookup guide]
* [https://cdn-learn.adafruit.com/downloads/pdf/32x16-32x32-rgb-led-matrix.pdf?timestamp=1543806512/ Wiring and pin information]
* [https://www.riyas.org/2013/12/online-led-matrix-font-generator-with.html Hex code generator to build LED matrix models]

====== MP3 Decoder and Frequency Analyzer ======
* [https://www.sparkfun.com/datasheets/Components/General/MSGEQ7.pdf Seven Band Graphic Equalizer MSGEQ7 Data Sheet]
* [https://www.kr4.us/SparkFun-MP3-Player-Shield.html?gclid=EAIaIQobChMIov3f7PWc2wIVDtVkCh0-rgStEAYYASABEgIEgPD_BwE SparkFun-MP3-Player-Shield Datasheet]

====== Gesture & Orientation Sensors ======
* [https://cdn.sparkfun.com/assets/learn_tutorials/3/2/1/Avago-APDS-9960-datasheet.pdf Gesture Sensor Data Sheet]
* [https://learn.sparkfun.com/tutorials/mma8452q-accelerometer-breakout-hookup-guide/all Accelerometer Sensor Data]

====== General/Miscellaneous ======
* [http://socialledge.com/sjsu/index.php/FreeRTOS_Tutorial FreeRTOS Tutorial]
* [https://sjsu-dev2.readthedocs.io/en/latest/?badge=latest SJTwo-c Documentation]

F19: Infinity Mirror

2019-12-18T23:40:08Z

Proj user22: /* Introduction & Objectives */

== '''Abstract''' ==

The main theme of the project is to build an interactive embedded system consisting of two entertainment modes - Music and Gaming. On the music mode, the MP3 decoder module reads songs from an SD card on the MCU board and plays the music through a speaker. It deals with the convergence of various services such as playing a game with background music, control volume, switch and pause/play songs. While the song is being played, audio frequency spectrum bands based on music tune are displayed on the LED Matrix band visualization etc. On the game mode, a fruit smashing game called “Fruit Fury” is implemented where the user needs to orient the MCU board in a direction according to where the fruit appears on the LED matrix. Alongside, the user can listen and switch songs. To achieve the above functionalities, various elements such as Audio Decoder, Audio frequency analyzer, 32x64 RGB LED Matrix and HC-05 bluetooth module and Android application are integrated.

[[File:High_level1.png|800px|thumb|center|Block Diagram of Infinity Mirror]]

== '''Introduction & Objectives''' ==

The key features supported by the system is real-time orientation recognition & trigger respective actions in 2 modes - MP3 mode and Game mode.

MP3 MODE:

1. Determine the accelerometer sensor values based on the orientation of the board and perform music control such as play, pause, volume control and changing songs.

2. In response, retrieve the data from the SD Card & communicate to the audio decoder for appropriate audio streaming.

3. Also implemented interaction with HC-05 bluetooth module through a customized mobile application and provide same operations.

4. Display frequency spectrum bands in sync to the tune of the song played.

[[File:frequency_bands.png|800px|thumb|center|Frequency bands]]

GAME MODE - Fruit Fury:

1. Determine the accelerometer sensor values based on the orientation of the board and hit the fruit in corresponding direction.

2. Incorporating provision on the board's switches to change to next or previous song.

3. Also implemented interaction with HC-05 bluetooth module through a customized mobile application and play the game through the same.

[[File:Title Screen.jpeg|800px|thumb|center|Title Screen]]

'''Project Objectives'''
'''1. Audio Decoder''' - Fetches song data from the SD card and plays it over a speaker.
'''2. RGB LED Matrix''' - Display frequency bands on music mode or view the game on game mode.
'''3. Audio Frequency Analyzer''' - To convert the audio data into 7 spectrum bands which is then displayed as individual colored bands on the LED matrix.
'''4. Bluetooth HC-05''' - Interfaces the system using Bluetooth to an Android application.

'''Team Objectives'''
'''1.''' Learn each and every module as much as possible, in order to develop an overall product.
'''2.''' Understand the proper use of queues and semaphores in order to send/receive the data between multiple tasks.
'''3.''' Learn to integrate all modules and ensuring smooth transition, communication and context switching at desired time intervals.
'''4.''' Document and track all the bugs encountered during development and learn to update git repository after every fix.

== '''Team Members & Technical Responsibilities''' ==
[[File:cmpe244_F19_Infinity_Mirror_members.jpeg|thumb|500x500px|TEAM INFINITY MIRROR|right]]

*'''''[http://linkedin.com/in/aakash-chitroda-17841740 Aakash Chitroda]'''''
** MP3 Audio Encoder/Decoder
** Audio frequency Analyzer logic

*'''''[https://www.linkedin.com/in/ganeshram93 Ganesh Ram]'''''
** Interfacing of LED Matrix and driver design
** Game logic design
** Audio frequency spectrum logic on LED
** Packaging

*'''''[https://www.linkedin.com/in/niket-naidu-30090a134/ Niket Naidu]'''''
** Android & Bluetooth Application
** OLED Interfacing and Designing
** PCB Design improvements
** Accelerometer Sensor integration with OLED Screen

*'''''[https://www.linkedin.com/in/vidushi-jain-048b992a Vidushi Jain]'''''
** Bluetooth Communication
** Interfacing of Gesture & Accelerometer Sensors
** Hardware Designing & PCB Integration

 

== '''Administrative Responsibilities''' ==
{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|- style="vertical-align: top;"
! colspan="5" style="background:#588ecc" | Administrative Roles 
|-
! style="text-align: left;" |
* Team Lead 
| Aakash Chitroda 
|-
! style="text-align: left;" |
* Finance Manager
| Niket Naidu 
|-
! style="text-align: left;" |
* Git Repository Manager 
| Vidushi Jain 
|-
! style="text-align: left;" |
* Wiki Report Manager 
| Vidushi Jain 
 Ganesh Ram 
|-
! style="text-align: left;" |
* Bill of Materials Manager 
| Ganesh Ram 
|}

== '''Team Deliverables Schedule''' ==

{| class="wikitable"
|-
! scope="col" style="text-align: left;" style="background:#588ecc;" | WEEK
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
START DATE 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
END DATE 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
TASK DETAILS 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
STATUS 
|-
| 1 || 15 Oct 2019 || 22 Oct 2019 ||
*Create and establish GitLab repository
*Establish slack channel and invite Preet
*Look through previous years projects and study it
*Distribute major roles among team members
|| Completed Completed Completed Completed 
|-
| 2 || 23 Oct 2019 || 29 Oct 2019 ||
* Create a Bill of Materials 
* Select and order Parts 
* Review Data-sheet and Interfacing Of LED Matrix(Ganesh) 
* Review Data-sheet for Gesture sensor(Vidushi) 
* Make Repo on Gitlab for all modules - Follow Naming Convention. 
|| Completed Completed Completed Completed Completed 
|-
| 3 || 30 Oct 2019 || 5 Nov 2019 ||
* Review Data-sheet of Audio MP3 shield(Aakash) 
* Start Soldering for LED matrix and MP3 Shield 
* Start Soldering of Headers for MP3 Shield & decoder
* Environmental setup of Android & Web applications(Niket) 
* Implementation of Gesture Detection (Vidushi)
* Implementation of displaying text and basic shapes on LED Matrix (Ganesh)
|| Completed Completed Completed Completed Completed Completed 
|-
| 4 || 6 Nov 2019 || 12 Nov 2019 ||
* Implementation of OLED Driver(Niket)
* Initialization the Audio Decoder through SPI communication and read manufacturer ID 
* Implementation of random frequency bands on LED matrix (Ganesh)
* Implementation of communication Between two task(gesture_detect & LED_Display) using queues and semaphores (Vidushi)
* Display Gesture Sensor Directions on OLED in a Text (Vidushi & Niket)
* Read Song from SD Card 
|| Completed Completed Completed Completed Completed Completed 
|-
| 5 || 13 Nov 2019 || 19 Nov 2019 ||
* Circuit Simulation in Diptrace/Eagle Tool. 
* PCB Layout Design in Diptrace/Eagle Tool. 
* Finalize Components placement on PCB. 
* Read Song from SD Card and send to MP3 Shield 
* Receive Values from audio spectrum and send to display task to display on LED Matrix.(Aakash & Ganesh) 
* Interface OLED with onboard buttons to access the list of songs (Niket)
* Developing logic for the ball movement and translating hand-gesture control into LED movement.(Ganesh)
|| Completed Completed Completed Completed Completed Completed Completed 
|-
| 6 || 20 Nov 2019 || 26 Nov 2019 ||
* Interfacing of all modules sensors, bluetooth , MP3 and LED Matrix
* Test whole implementation after integration of all modules
* Test for stack overflow and system crash
* Debug and Test the Play/Pause/Stop functionality of MP3 player 
* Integrate fruit Fury game logic
* Update Final Wiki Schedule. 
|| Completed Completed Completed Completed Completed Completed Completed 
|-
| 8 || 27 Nov 2019 || 3 Dec 2019 ||
* Additional Feature week
* Establish Bluetooth communication of Device and Mobile APP 
* Develop UI on Android application. 
* Add Play/Pause/Stop and Song selection functionality to the APP. 
* Update Wiki with new details and information. 
* Enhanced game logic and integrated song play feature in game 
|| Completed Completed Completed Completed Completed 
|-
| 9 || 4 Dec 2019 || 10 Dec 2019 ||
* TESTING - CRITICAL WEEK 
* Packaging of hardware board and related components. 
* Check overall robustness of the complete system. 
* Establish complete connection on PCB 
* Update wiki with details. 
|| Completed Completed Completed Completed Completed 
|-
| 10 || 11 Dec 2019 || 17 Dec 2019 ||
* All hands on testing and final bug fixes. 
* Check for tuning or calibration of sensors if required. 
* Complete end-to-end testing for various scenarios and conditions. 
* Create the semester long project activity video and upload to YouTube. 
* Update and finalize wiki. 
|| Completed Completed Completed Completed Completed 
|-
| 11 || 18 Dec 2019 || ||
* '''DEMO: Final Project''' 
* '''SUBMISSION: Final Project Wiki''' 
|| Completed Completed 
|}

== '''Bill of Materials (General Parts)''' ==

{| class="wikitable"
|-
! scope="col" style="text-align: left;" style="background:#588ecc;" | PART NAME 

! scope="col" style="text-align: left;" style="background:#588ecc;" | 
PART MODEL & SOURCE 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
QUANTITY 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
COST PER UNIT (USD) 
|-
|
* Micro-Controller Eval-Boards
|
* LPC 4078 (Purchased from Preet Kang)
|
* 1
|
* 50.00

|-
|
* Audio decoder Breakout Board
|
* [https://www.sparkfun.com/products/12660 SparkFun MP3 Player Shield]
|
* 1
|
* 26.95

|-
|
* Audio Analyzer
|
* [https://www.amazon.com/dp/B074T9H8JV/ DFR0126 Audio Analyzer]
|
* 1
|
* 19.00

|-
|
* RGB LED matrix
|
* [https://www.sparkfun.com/products/14718 32 x 64 RGB LED Matrix Panel]
|
* 1
|
* 49.95

|-
|
* Power supply
|
* [https://www.sparkfun.com/products/15352 5V / 4A Power Supply]
|
* 1
|
* 12.95

|-
|
* Audio Speakers
|
* 3.5mm Jack Stereo Speakers
|
* 1
|
* Own

|-
|
* PCB parts and other Miscellaneous parts
|
* Anchor Electronics and Digikey '''
|
* 1
|
* 50.00

|-
|
* 2 way mirror
|
* [https://www.amazon.com/gp/product/B06Y2C79FC/ref=ppx_yo_dt_b_asin_title_o03_s00?ie=UTF8&psc=1 2-way mirror ]
|
* 1
|
* 7.64

|-
|
* PCB Fabrication
|
* [https://jlcpcb.com/quote JLCPCB]
|
* 5
|
* 29.53
|}

 

== '''Printed Circuit Board''' ==

=== Design And Architecture ===

We have designed the custom PCB using Eagle Software and as well as one prototype board in which we have connected all the modules with SJ-Two board. PCB was sent to fabrication to JLCPCB China which provided PCB with lead time of 1 week. We have implemented 2 layers of PCB with all of the parts in top layer.

'''Components Placements on PCB and on Prototype Board'''
'''1.''' One SJ-Two board is fitted onto the top of the 3D printed lid cover which with a slot opening for 2x40 IDC cable.
'''2.''' MP3 Decoder is connected with SJ-Two board and will be place on the right side of PCB and as well as on Prototype board.
'''3.''' Bluetooth Module needs only 4 pins to connect with SJ-Two and goes to UART3 and placed on the top left of the board.
'''4.''' LED Matrix is connected using 2x8 IDC cable pins on the top left side of the board.
'''5.''' Audio Frequency Analyzer is placed on the bottom side of PCB.
'''6.''' Power supply of 5v and 3.3v provisions are made on the bottom left side of PCB.

{|
[[File:Top_Layout.png|500x600px|thumb|left|Top Layer PCB Design On Eagle Software]]
|[[File:Bottom_Layout.png|500x600px|thumb|right|Bottom Layer PCB Design on Eagle Software]]
|}

{|
[[File:Top_View.png|500x600px|thumb|left|PCB Top Layer]]
|[[File:Bottom_View.png|500x600px|thumb|right|PCB Bottom Layer]]
|}

'''Infinity Mirror's Internal Circuit'''

[[File:Setup.jpeg|thumb|350x350px|center|Infinity Mirror: Internal Circuit of Embedded Entertainment Box]]

=='''Product Enclosure''' ==

To facilitate easy and convenient gaming experience and also act as an effective audio controller, a single 3D printed enclosure was designed which is spacious enough to accommodate the MCU modules like bluetooth, audio frequency analyzer and MP3 decoder on the PCB.

{|
|[[File:Top.jpeg|470px|thumb|left|Top View]]
|[[File:3D.png|430px|thumb|right|3D View]]
|}

===Final 3D Package===
[[File:Final_Setup.jpeg|thumb|600x600px|center|Infinity Mirror: Final Setup]]

=='''RGB LED Matrix'''==
A 32 x 64 RGB LED Matrix will be powered up through a 5V/4A DC adapter and is interfaced with the board to play the game 'Fruit Fury' with desired background song in the game-mode and to display the frequency bands and other relevant messages such as "Next", "Previous" and "Pause" in the music-mode. Only the INPUT IDC connector will be used because we are not cascading multiple matrices. The matrix has 2 planes (upper and lower), both of which will be programmed separately. In order to set RGB color data for each pixel in plane 1 (top half of the display) we use R1, G1 and B1 pins and for plane 2 we use R2, G2 and B2. By setting and resetting the CLOCK pulse, color data is set for every pixel in the row. Then the LATCH is set to mark end of the row and reset to move to next row. All of these steps are repeated at very less time intervals so that the human eye perceives it as one complete frame (Persistence of Vision).

Below is the description of the pins:

*R1 -> Sets upper panel's Red data
*G1 -> Sets upper panel's Green data
*B1 -> Sets upper panel's Blue data
*R2 -> Sets lower panel's Red data
*G2 -> Sets lower panel's Green data
*B2 -> Sets lower panel's Blue data
*A -> Sets row bit 0
*B -> Sets row bit 1
*C -> Sets row bit 2
*D -> Sets row bit 3
*CLK (Clock) -> Set to access each pixel
*LAT (Latch) -> Set to mark comletion of one row
*nOE (Output Enable) -> Set to switch the LEDs off when transitioning from one row to the next
*GND -> Ground pins to be connected with board's GND.

Below are the technical specifications:

*Pitch -> 4 mm
*Resolution -> 32 x 64 = 2048 dots
*Panel dimensions (l x b x h) in mm -> 256 x 128 x 13
*Working voltage/current rating -> 5v / 4A (max)
*Scan rate - 1/16
*Pixel component configuration (R,G,B) -> 1,1,1
*Weight -> 0.24 kg

=== Hardware Design ===
The hardware involves 5V/4A DC power supply adapter, barrel jack connectors and IDC cables to power up the LED matrix and communicate with the board. Below is the pin interfacing diagram.
[[File:Slide2.png|700x900px|thumb|center|LED Matrix Pin Diagram]]

=== Software Design ===
1. '''Fruit Fury - Game mode''' 

There are 2 tasks involved to ensure functioning of the game.

a) Task 1:
*Display the game's title screen. On pressing the onboard switch (SW1), game begins.
*Also used to display game over screen / win screen.
b) Task 2:
*Enter into game mode to play the game.
*Read accelerometer values (board orientation) and render game frame.
*Detect the player's board movement, compare it with fruit's location.
*Display score, lives and smash effects.
*Press another switch (SW0) to stop game and return to title screen or to restart the game once it is over.

 '''Game rules:''' 

a) Game comprises of 3 levels (level 2 on reaching score 15 and level 3 on reaching score 30) and 5 lives in total.

b) Primary objective is to tilt the board to the direction (North West, North East, South West or South East) in which the fruit appears in order to smash it.

c) Score increases by 1 point for smashing each fruit.

d) Bombs start appearing after completion of level 1, which costs a life when hit.

e) Level 3 is faster so make sure you tune your reflexes up.

f) Reach score 50 to win the game.

 '''Bonus:''' 

a) Streaks are rewarding. Smash 10 fruits straight up to win an extra life.

b) Look out for star fruits. Hit them to gain +2 points.

Choose your song to take all the inspiration you can and start smashing!

 '''2. Music mode''' 

a) Press the button to enjoy music-only mode. Graceful audio spectrum bands are displayed that dance to the tune of the chosen song.

b) A display is prompted to the user whenever music is paused or changed to next or previous song.

=== Implementation ===
'''LED Driver'''

1. Initialize the LED matrix by configuring necessary pin directions.

2. Disable Output Enable (OE) GPIO before feeding matrix data.

3. Select the required row by setting bits on A, B, C, D GPIO pins.

4. Loop through the pixels (columns) in the selected row and set the pixel color on R, G, B GPIO pins.

5. Set zero on R, G, B GPIO pins to mask that particular pixel.

6. Set and Reset the clock for pushing the R, G, B bits for each column.

7. Issue latch to mark the row's completion and reset latch before going to next row.

8. Follow the steps 2 to 7 for other rows.

<source lang="cpp">
for (uint8_t row = 0; row < (MAX_ROW / 2); row++) {
disableOE();
set_row(row);
for (uint8_t col = 0; col < MAX_COL; col++) {
LPC_GPIO0->PIN |= (1 << CLK);
set_color_bottom(game_matrix[row + (MAX_ROW / 2)][col]);
set_color_top(game_matrix[row][col]);
LPC_GPIO0->PIN &= ~(1 << CLK);
}
LPC_GPIO0->PIN |= (1 << LAT);
LPC_GPIO0->PIN &= ~(1 << LAT);
enableOE();
vTaskDelay(1);
}
</source>

'''Fruit Fury - Game mode'''

1. Generate the fruit's initial coordinate using random function (used srand() with time value as seed to get random pattern sets).

2. Construct the LED matrix array by drawing the fruit and borders.

3. Push the entire matrix data to LED driver to display the constructed matrix frame.

4. Then read the player's orientation and match with fruit's direction.

5. Modify game parameters (score, lives and level) based on player's results.

6. Stop game if all lives are over and display game over screen by switching to game init task (Task 1).

<source lang="cpp">
/* Push button to exit game */
if (LPC_GPIO0->PIN & (1 << SW0))
is_start_game = false;

if (is_start_game == true) {
/* Generate fruit's initial coordinate position */
get_fruit_begin_coord(&row_pt, &col_pt, &quadrant);
/* Generate final frame by considering fruit object at that position */
construct_game_matrix(row_pt, col_pt);
/* Draw final frame matrix of the game */
draw_final_game_frame();
/* Get the board direction from the user and increment score count */
compute_game_params(row_pt, col_pt, quadrant);
} else
vTaskResume(display_game_init_screen_t);
</source>

'''Spectrum display - Music mode'''

1. Read the audio frequency values from the graphic equalizer task and store it as an array.

2. Based on value of each frequency band, assign a height of the band (in pixels) to be drawn on the LED matrix.

3. Set a unique color for each band.

3. Push the entire matrix data to LED driver to display the constructed matrix frame.

4. Repeat steps 1 to 3 at required intervals to display repeating bands.

<source lang="cpp">

for (row = MAX_ROW - 1; row >= 1; row--) {
for (col = 7; col <= 62; col++) {
if ((row >= (MAX_ROW - band_height[0])) && col >= 7 && col <= 13 &&
band_num <= 0) {
band_matrix[row][col] = RED;
}
if ((row >= (MAX_ROW - band_height[1])) && col >= 14 && col <= 20 &&
band_num <= 1) {
band_matrix[row][col] = GREEN;
}
if ((row >= (MAX_ROW - band_height[2])) && col >= 21 && col <= 27 &&
band_num <= 2) {
band_matrix[row][col] = YELLOW;
}
if ((row >= (MAX_ROW - band_height[3])) && col >= 28 && col <= 34 &&
band_num <= 3) {
band_matrix[row][col] = BLUE;
}
if ((row >= (MAX_ROW - band_height[4])) && col >= 35 && col <= 41 &&
band_num <= 4) {
band_matrix[row][col] = PURPLE;
}
if ((row >= (MAX_ROW - band_height[5])) && col >= 42 && col <= 48 &&
band_num <= 5) {
band_matrix[row][col] = CYAN;
}
if ((row >= (MAX_ROW - band_height[6])) && col >= 49 && col <= 55 &&
band_num <= 6) {
band_matrix[row][col] = WHITE;
}
}
}

</source>

=='''MP3 Decoder'''==

The Audio Decoder breakout board communicates with the SJ board over SPI and is interfaced with the SPI-0 pins of the SJ board as follows:

*Clock Pin (Pin 13) - SJ SPI-0 Clock Pin
*MISO Pin (Pin 12) - SJ SPI-0 MISO Pin
*MOSI Pin (Pin 11) - SJ SPI-0 MOSI Pin
*MP3 CS: Chip Select Pin for the audio decoder to be activated while sending control signals.
*MP3 DCS: Chip Select Pin for the audio decoder to be activated while sending audio data signals.
*MP3 RST: Reset pin for the audio decoder.
*MP3 DREQ: Data Request Pin. Audio decoder signals that it is ready to accept next 32 bytes of audio data.
*VCC pin - SJ 3.3V pin
*GND pin - SJ GND Pin

=== Hardware Design ===
[[File:Slide1.png|800x900px|thumb|center|MP3 Decoder Pin Diagram]]

=== Software Design ===

[[File:Mp3_fLow.png|600x500px|thumb|center|MP3 Decoder Software Design]]

=== Implementation ===

We are interfacing MP3 Decoder on the SPI0 for reading the Audio Mp3 file from the SDCard and send Mp3 data to the Decoder. The purpose of this task is to send mp3 data to the mp3 decoder. This is a high priority as it is acting as a consumer. The producer task in our project is the task that reads songs that fill the freeRTOS queue with 4KB of data. The consumer task i.e the task that sends a song to the mp3 decoder that waits on an empty queue for portMAX_DELAY. Once the queue has data, the task starts sending 32 bytes at a time to the MP3 decoder. Once 32 bytes are sent, the task waits for the DREQ pin to get high. DREQ pin high indicates that the MP3 decoder unit is ready to take 32 bytes of data. For sending data, the task acquires the MUTEX so that no other task can use the SPI bus at the same time. Once the 32 bytes are sent, the MUTEX is released. This is the working of the task.

// Task to send data to decoder(High priority)
static uint8_t bytes_to_be_sent_to_decoder[READ_BYTES_FROM_FILE];
static uint8_t current_count = 0;
uint32_t start = 0, end = 0;
while (1) {
if (0 == current_count) {
xQueueReceive(mp3_queue, &bytes_to_be_sent_to_decoder[0], portMAX_DELAY);
}
start = (current_count * TRANSMIT_BYTES_TO_DECODER);
end = ((current_count + 1) * TRANSMIT_BYTES_TO_DECODER);
while (!mp3__dreq_get_status()) {
mp3__decoder_refresh();
vTaskDelay(2);
}
if (xSemaphoreTake(mp3_mutex, portMAX_DELAY)) {
mp3__data_cs();
send_32_bytes_to_decoder_using_ssp(start, end,
&bytes_to_be_sent_to_decoder[0]);
mp3__data_ds();
xSemaphoreGive(mp3_mutex);
if (current_count == COUNT - 1) {
current_count = start = end = 0;
} else {
current_count += 1;
}}}

=='''Audio Frequency Analyzer'''==

In the audio analyser, strobe and reset pins are used to select the DC peak output. Reset high resets the multiplexer. Reset low enables the strobe pin. At the leading edge of the first strobe, the first frequency band 63Hz is on the output. On each additional leading edge strobe the next frequency band(160Hz, 400Hz, 1kHz, 2.5kHz, 6.25kHz, 16kHz) is detected.

This analyser takes input from Audio decoder for left and right side music. SJ2 controls the RS and ST pins of the "Audio Frequency Analyzer" and reads input data from S pin which is connected to ADC pin (P0.26) of SJ2 board.

*Audio Analyzer S pin -> SJ2 ADC4 pin
*Audio Analyzer RS pin -> SJ2 P0.11 pin
*Audio Analyzer ST pin -> SJ2 P2.0 pin
*Audio Analyzer + pin -> SJ2 VCC pin
*Audio Analyzer - pin -> SJ2 GND pin
<div style="clear: both"></div>

====Audio Frequency Analyser====
Audio frequency analyser is working is most important task in order to get correct value. Incorrect initialisation and in efficient delays may cause error. In this project Init and reading of data at each frequncy band is implemented based on timing diagram shown as bellow:

[[File:244 Spark TimingDiagram AudioAnalyser.jpeg|thumb|550x400px|centre|Timing Diagram of Audio Analyser]]

The software Implementation to Init frequency analyser is as follow: 
1. Select ADC pin 
2. Select GPIO pin direction for reset pin and STOBE pin 
3. Reset Audio frequency analyser 

=='''Sensors Interface'''==

We have worked on two sensors for accessing our entertainment box i.e. Gesture Sensor and Accelerometer. The SJ-Two board has both sensors on board sensor which is interfaced on the I2C bus. Accelerometers are electromechanical devices that sense either static or dynamic forces of acceleration. Static forces include gravity, while dynamic forces can include vibrations and movement. The measurements are on 3-axis and these values can be calibrated to find the desired values.

In our project, an accelerometer is for controlling Controls in the MP3 Mode like PLAY,PAUSE,PLAY Next Song and Back to Previous Song.However in Game Mode we are playing our fruit fury game using Orientation sensor for Smashing fruits coming in Directions South East, South West ,North East and North West and We were using Gesture on SJ-Two Board for gesture recognitions Left, Right, UP and Down to change the configuration in MP3 Mode but after implementation we have realised that giving gesture is more complicated then getting signals from orientation.

=== Hardware Design ===

[[File:Sensor.png|800x900px|thumb|center|APDS9960 & MMA8452Q on board Sensors]]

=== Software Design ===

[[File:Sensor_FLow.png|600x500px|thumb|center|MMA8452Q Software Design]]

=== Implementation ===
The MMA8452Q has an orientation detection algorithm with the ability to detect all six orientations but we are using only 4 orientations i.e. Portrait Up, Portrait Down,Landscape Left and Landscape Right .The transition from portrait to landscape is fixed with a 45° threshold angle and a ±14° hysteresis angle. This allows the for a smooth transition from portrait to landscape at approximately 30° and then from landscape to portrait at approximately 60°.

[[File:accel_orient.png|800x900px|thumb|center|Portrait Orientation]]

We have used the following register settings to configure the sensors and getting all 4 directions and Orientation.

[[File:APDS_Register.png|800x900px|thumb|center|Registers of APDS9960]]

 

After reading the registers we are just performing the actions as per the Orientation detected.

[[File:Accel_register.png|800x900px|thumb|center|Registers of MMA8452Q]]

 

void perform_action_on_orientation(void *p)
{
orientation_e value;
while (1)
{
value = GetOrientation();
switch (value)
{
case Portrait_UP: // Prev Song
printf("Direction Left\n");
xSemaphoreGive(sem__prev_song);
break;
case Portrait_DOWN: // Next Song
printf("Direction Right\n");
xSemaphoreGive(sem__next_song);
break;
case Landscape_LEFT: // Resume/Play/
printf("Direction Up\n");
vTaskSuspend(handle__play_song);
vTaskSuspend(handle__freq_bands);
song_status = PLAY;
break;
case Landscape_RIGHT: // Pause/Stop/Volume Decrease
printf("Direction Down\n");
vTaskResume(handle__play_song);
vTaskResume(handle__freq_bands);
song_status = PAUSE;
break;
default:
break;
}
vTaskDelay(50);
}}

=='''Bluetooth Interface'''==
The SJ-two is connected to the Bluetooth module through the Serial interface (UART3) and we have configured it at 38400 baud rate with 8-bit data and 1 stop bit using the Communication Mode. It is used to send and receive the Game and Music data from our entertainment device to an android application.

=== Hardware Design ===

[[File:Slide3.png|700x900px|thumb|center|Bluetooth Interface Pin Diagram]]

===HC-05 Bluetooth module===
HC-05 Bluetooth Module is used to set up wireless communication between the entertainment device and the Android phone. The right section of the Bluetooth Board has connection pins for power and signals as well as a 5V to 3.3V Regulator, LED, and level shifting.

'''HC-05 PinOut'''
* EN: N/A
* VCC: 5V Power
* GND: Ground
* TXD: Serial Transmit pin connected to RXD3 of SJ board
* RXD: Serial Receive pin connected to TXD3 of SJ board
* STATE: States if connected or not

=== Software Design ===

[[File:Bluetooth_Sw_diagram.png|600x500px|thumb|center|Bluetooth Software Design]]

=== Implementation ===

An accelerometer is used in the MP3 Mode to implement functionalities such as play, pause, switch to next and previous songs and volume control. In the game mode the “Fruit fury” game is played by smashing fruits appearing in the directions South East, South West, North East and North West. UART3 is used as communication protocol.The Bluetooth commands that we are using to interact with Mobile app and Device are as follows:

GAMING = 0xA1,
NORTH_EAST = 0x71,
NORTH_WEST = 0x72,
SOUTH_WEST = 0x73,
SOUTH_EAST = 0x74,
MUSIC = 0xA2,
SONG_LIST = 0xA3,
NEXT_SONG = 0xC2,
TOGGLE_SONG = 0xC1,
PREV_SONG = 0xC0,
ACK = 0x00,
NACK = 0xFF,
VOL_INC = 0xB1,
VOL_DEC = 0xB0

=='''Mobile Application'''==

{|
|[[File:Modes.jpeg|230px|thumb|List Of Feature in the APP]]
|[[File:GAME.jpeg|230px|thumb|Game Mode]]
|[[File:Mp3_song.jpeg|230px|thumb|MP3 Mode]]
|[[File:SongList.jpeg|230px|thumb|List Of Songs in SD Card]]
|}

=== Software Design ===

The Android app has been built using the cross platform framework [https://flutter.dev/ Flutter]

The app is composed of 3 parts, '''Game Mode''', '''MP3 Mode''' and '''MP3 Song List'''. On the main screen we first connect to the bluetooth before establishing connection with any of the modes. The working of each mode is explained in each subsection below.

A few variables to note in advance
ACK = 0x00, sent when successful
NACK = 0xFF, sent incase there is any error

====1. Game Mode ====

Wireless communication with the Entertainment box communication over Bluetooth protocol. Android Application is created which provides an interface to exchange data and configure the device.To enter the Game Mode screen we first check if the Bluetooth Connection is established. We send in a one byte data 0xa1 over bluetooth to the SJ2 Board and get back the response "a1$ack/nack$##" We then enter the game mode which displays a joystick that can be oriented to a direction wherever the fruit appears on the LED matrix. The corresponding orientation value is then transmitted.If the fruit had appeared in any of the quadrant then will send data from BLE APP to SJTwo Board.

'''1.''' First Quadrant (North-East): 0x71 
'''2.''' Second Quadrant (North-West): 0x72 
'''3.''' Third Quadrant (South-West): 0x73 
'''4.''' Fourth Quadrant (South-East): 0x74 

====2. MP3 Mode ====

To enter the MP3 Mode screen we first check if the Bluetooth Connection is established similar to the Game Mode. We send in one byte of data 0xa2 over bluetooth to the SJ2 Board and get back the response "a2$ack/nack$volumeInfo$currentSong$isPlaying/isPaused$##" where isPlaying is 1 and isPaused is 0. These values are loaded into the MP3 Mode Screen as initial values for the current song playing. We can then see a screen where we can control the various aspects of playing songs i.e Playing and Pausing the song, Go to next song and and Go to the previous song. We can also control the volume remotely.Controlling each part of this interface is the same as sending a single byte of data over bluetooth to the SJ2 Board.

'''1.''' Playing and Pausing Song - We just toggle the state of the Song. We issue this command by sending 0xc1 which is the Toggle State command. 
'''2.''' Next Song and Previous Song - Command for the previous and next song is 0xC0 and 0xC2. 
'''3.''' Control Volume remotely - For volume we divide the percentage 100 percent in 16 parts. We can send the value between 0xb0 to 0xbf in increments of one step. This is parsed on the SJ2 Board and converted to an equivalent volume signal. 

====3. MP3 Song List ====
To get the list of MP3 Songs which are present in the SD card, we first check if the Bluetooth Connection is established similar to the Game Mode and MP3 Song mode. We send in one byte of data 0xa3 over bluetooth to the SJ2 Board and get back the response "a3$ack/nack$data$data$...$##". APIs that were designed to read song information and data by Audio Decoder, will be used for achieving this functionality.

=='''OLED Screen'''==

[[File:Oled_screen.jpeg|thumb|600x600px|center|Oled Screen Functionality]]

=== Software Design ===

The open source package [https://github.com/olikraus/u8g2 u8g2] has been used.
There are already ready made functions for various OLED Drivers. The indepth setup guide can be found [https://github.com/olikraus/u8g2/wiki/u8g2setupc here]

=== Implementation ===

The u8g2 library is a very robust library which means that this code can be extended for any microcontroller as long as the interface is written properly.

We needed to write 2 main functions, outlined below, i.e byte_cb and gpio_and_delay_cb using the function prototype `uint8_t u8x8_lpc_gpio_and_delay(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr)`.

Since the SJ2 Board is connected to the OLED Screen on the SPI1 Bus we also need to write the SPI1 driver, mainly a method to that sends data over SPI to the Slave device i.e the OLED Screen

=== Initializing the u8g2 for LPC4078 ===

<source lang="cpp">

// Created a file `u8g2_wrapper.h

static gpio_s dc;
static u8g2_t u8g2;

void u8g2_wrapper__init(gpio_s *dc_pin) {
u8g2_Setup_ssd1306_128x64_vcomh0_1(&u8g2, U8G2_R0, u8x8_byte_4wire_hw_spi, u8x8_lpc_gpio_and_delay);
u8g2_InitDisplay(&u8g2);
u8g2_SetPowerSave(&u8g2, 0);

dc.pin_number = dc_pin->pin_number;
dc.port_number = dc_pin->port_number;
}

u8g2_t *u8g2_wrapper__get_instance() { return &u8g2; }

uint8_t u8x8_lpc_gpio_and_delay(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr) {
switch (msg) {
case U8X8_MSG_GPIO_AND_DELAY_INIT:
delay__ms(1);
break;
case U8X8_MSG_DELAY_MILLI:
delay__ms(arg_int);
break;
case U8X8_MSG_GPIO_DC:
// DONE, Write to the GPIO_DC Pin
if (arg_int == 0) {
gpio__reset(dc);
} else {
gpio__set(dc);
}
break;
case U8X8_MSG_GPIO_RESET:
break;
}
return 1;
}

uint8_t u8x8_byte_4wire_hw_spi(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr) {
uint8_t *data;
switch (msg) {
case U8X8_MSG_BYTE_SEND:
data = (uint8_t *)arg_ptr;
while (arg_int > 0) {
ussp1__exchange_byte((uint8_t)*data);
data++;
arg_int--;
}
break;
case U8X8_MSG_BYTE_INIT:
break;
case U8X8_MSG_BYTE_SET_DC:
if (arg_int == 0) {
gpio__reset(dc);
} else {
gpio__set(dc);
}
break;
case U8X8_MSG_BYTE_START_TRANSFER:
break;
case U8X8_MSG_BYTE_END_TRANSFER:
break;
default:
return 0;
}
return 1;
}

</source>

=='''Technical Challenges'''==

1. '''RGB LED Matrix''' 

* Getting control of the matrix was challenging as it needs to follow specific sequence of pin enabling/disabling at appropriate timing.

* Setting right delays to avoid flickers and get smooth transitioning between frames by using delays or for loops.

* Fixing high CPU utilization by changing delay__us to vTaskDelay.

* Designing elements of the game (title screen and fruit objects) which required careful plotting of pixel data.

2. '''Audio Decoder''' 

a) The CPU utilization for sending a song task was very high (80% +).
* In order to reduce the utilization, we gave the vTaskDelay(1) while waiting for the DREQ to be high. The high DREQ indicates that the decoder is ready to receive next 32 bytes of data. So meanwhile, when the DREQ pin is low, we made task to sleep for vTaskDelay(1). After doing this, we significantly reduced the CPU utilization to 15%. We tried with vTaskDelay(2) to get CPU utilization of 10%.
* We further tried to make the CPU utilization below 10%. This was really a tough challenge, and figured out that the actual SPI clock is 1Mhz which is too slow as SPI is meant to operate at much higher speed. We changed the clock rate of SPI to 12MHz but the song speed was too slow. We checked the datasheet of the Mp3 decoder and set the internal clock multiplier to 4.5x. This make the shield operate at high clock rates at 12.XX Mhz. So keeping this in mind we made the SPI speed to 12MHz which is safe. We successfully achieved CPU utilization of 5-6% which is very much in the acceptable range.

3. '''PCB Designing''' 

* We realized that using GPP for long term is not a good idea. Initially we spent time in debugging our hardware and later we have realized like we can’t take this for our final day.
* We did multiple reviews before ordering our final PCB as none of us did that earlier. We have faced issue in manual routing on Eagle Autodesk but our ISA Prashant helped us and he reviewed our PCB design twice.

4. '''Mobile Application''' 

* The main challenge of the Mobile application was to make the UI interactive while getting data asynchronously over the Bluetooth module.
* There was a global listener stream implemented that got the value and concatenate the string till we received the end frame (##).
* However the challenge still existed to know which screen has called what data which prompted us to create the key and ACK/NACK pair in the start.
* The Mobile app is completely data reactive, which means that the UI components render and change according to the data provided. This caused a lot of issues mainly since we tried polling methods to make sure that the UI remains up to date with the STATE of the SJ2 Board.
* A manual approach was opted for mainly to make the system more deterministic and for better debugging capabilities.

=='''Suggestions for Future Students'''==
 '''RGB LED Matrix''' 

* To begin with, focus on writing a simple driver to get control of 1 pixel at a targeted location and then use appropriate loops to light up the entire row/column.

* Make sure all pixels are able to light up with all possible colors to eliminate hardware defects.

* Try with minimum / no delays, print tick counts and then come up with meaningful delay numbers.

* Optimize the code (minimum delays, avoiding repetitive function calls, etc.) to bring down the CPU usage level.

* Use the link in the references to draw desired elements and generate the matrix.

 '''Tips for getting GOOD Grades and to remain in top 3 teams''' 
* Select your teammates wisely, and make sure every one dedicates themself for this project.
* Be an active member of your team and review rubrics for the final DEMO.
* As soon as the professor mentions the project, please start working on the project otherwise, in the end, you have to struggle with finals and you will be left with less time for testing and you have to struggle in demo.

 '''General tips''' 
* Remember the KISS approach when you code. (Keep It Simple and Stupid).
* For this project, one should know the basics in C/ C++, FreeRTOS, and some good debugging skills. Because if you don't have one, you will eventually end up spending more time debugging your problem.
* Always give meaningful names to the variable or the function, so a third person reviewing the code gets an overall idea by just reading the name.

=='''Conclusion'''==
It was a really great working experience for all of us. We were really thrilled from the beginning that we will be working on something that is quite relevant in the industries. We worked as a team of four which helped us all to know the importance of team-work and co-ordination. We learned many great stuff like

* State Design using FreeRTOS
* FreeRTOS APIS when task handles are NULL vs when Initialised.
* Uses of extern and global variables as opposed to encapsulation i.e static inside private 'c' files.
* Learning Optimization through the integration of our peer's individual modules
* Improving CPU utilisation of the main LED and MP3 tasks.
* Workload sharing and cooperation amongst peers.
* Sharing ideas and debugging a common problem together i.e team building.
* We realised that using GPP for long term is not a good idea, there were some breakdown in the wires and our MP3 stopped working. Initially we spent a lot of time debugging hardware and doing soldering. So we started designing the PCB, and when our PCB was done, we spent hardly any time debugging the hardware.
* Git : We learnt all the basic of GIT and it plays an important to role for source code versioning.

There were a lot of problems while doing this project but it was a steep learning curve. In the end we were able to achieve our objective with really good results.

=='''Project Video'''==
https://youtu.be/vVjHCoyWYz4

=='''Project Source Code'''==
* Git Project Link (Individual Modules): [https://gitlab.com/Infinity_Mirror/infinity_mirror-cmpe-244]
* Git Project Link: [https://gitlab.com/ganeshram2493/infi_mirror]

=='''Project Presentation File'''==
* [https://drive.google.com/file/d/1Q_Xvs-a2feQcr-FbPEKbwmlhi35hqNxX/view?usp=sharing Presentation Link]

=='''References'''==
=== Acknowledgement ===

We would like to express our gratitude to Professor Preetpal Kang for generously sharing his time and knowledge with us and guiding us through the completion of this project. We would also like to thank the Prashant Gandhi(ISA) for their valuable advice and constructive feedback.

=== References Used ===

====== Flutter Android GUI ======
* [https://material.io/resources/icons/?style=baseline Material Design Icons]
* [https://flutter.dev/ Building a Dynamic UI with Flutter]
* [https://www.youtube.com/channel/UCwXdFgeE9KYzlDdR7TG9cMw Flutter Youtube Channel]

====== RGB LED Matrix Interfacing and Designing ======
* [https://www.sparkfun.com/products/14718 Datasheet and Hookup guide]
* [https://cdn-learn.adafruit.com/downloads/pdf/32x16-32x32-rgb-led-matrix.pdf?timestamp=1543806512/ Wiring and pin information]
* [https://www.riyas.org/2013/12/online-led-matrix-font-generator-with.html Hex code generator to build LED matrix models]

====== MP3 Decoder and Frequency Analyzer ======
* [https://www.sparkfun.com/datasheets/Components/General/MSGEQ7.pdf Seven Band Graphic Equalizer MSGEQ7 Data Sheet]
* [https://www.kr4.us/SparkFun-MP3-Player-Shield.html?gclid=EAIaIQobChMIov3f7PWc2wIVDtVkCh0-rgStEAYYASABEgIEgPD_BwE SparkFun-MP3-Player-Shield Datasheet]

====== Gesture & Orientation Sensors ======
* [https://cdn.sparkfun.com/assets/learn_tutorials/3/2/1/Avago-APDS-9960-datasheet.pdf Gesture Sensor Data Sheet]
* [https://learn.sparkfun.com/tutorials/mma8452q-accelerometer-breakout-hookup-guide/all Accelerometer Sensor Data]

====== General/Miscellaneous ======
* [http://socialledge.com/sjsu/index.php/FreeRTOS_Tutorial FreeRTOS Tutorial]
* [https://sjsu-dev2.readthedocs.io/en/latest/?badge=latest SJTwo-c Documentation]

File:Frequency bands.png

2019-12-18T23:39:42Z

Proj user22:

F19: Infinity Mirror

2019-12-18T23:37:30Z

Proj user22: /* Introduction & Objectives */

== '''Abstract''' ==

The main theme of the project is to build an interactive embedded system consisting of two entertainment modes - Music and Gaming. On the music mode, the MP3 decoder module reads songs from an SD card on the MCU board and plays the music through a speaker. It deals with the convergence of various services such as playing a game with background music, control volume, switch and pause/play songs. While the song is being played, audio frequency spectrum bands based on music tune are displayed on the LED Matrix band visualization etc. On the game mode, a fruit smashing game called “Fruit Fury” is implemented where the user needs to orient the MCU board in a direction according to where the fruit appears on the LED matrix. Alongside, the user can listen and switch songs. To achieve the above functionalities, various elements such as Audio Decoder, Audio frequency analyzer, 32x64 RGB LED Matrix and HC-05 bluetooth module and Android application are integrated.

[[File:High_level1.png|800px|thumb|center|Block Diagram of Infinity Mirror]]

== '''Introduction & Objectives''' ==

The key features supported by the system is real-time orientation recognition & trigger respective actions in 2 modes - MP3 mode and Game mode.

MP3 MODE:

1. Determine the accelerometer sensor values based on the orientation of the board and perform music control such as play, pause, volume control and changing songs.

2. In response, retrieve the data from the SD Card & communicate to the audio decoder for appropriate audio streaming.

3. Also implemented interaction with HC-05 bluetooth module through a customized mobile application and provide same operations.

4. Display frequency spectrum bands in sync to the tune of the song played.

GAME MODE - Fruit Fury:

1. Determine the accelerometer sensor values based on the orientation of the board and hit the fruit in corresponding direction.

2. Incorporating provision on the board's switches to change to next or previous song.

3. Also implemented interaction with HC-05 bluetooth module through a customized mobile application and play the game through the same.

[[File:Title Screen.jpeg|800px|thumb|center|Title Screen]]

'''Project Objectives'''
'''1. Audio Decoder''' - Fetches song data from the SD card and plays it over a speaker.
'''2. RGB LED Matrix''' - Display frequency bands on music mode or view the game on game mode.
'''3. Audio Frequency Analyzer''' - To convert the audio data into 7 spectrum bands which is then displayed as individual colored bands on the LED matrix.
'''4. Bluetooth HC-05''' - Interfaces the system using Bluetooth to an Android application.

'''Team Objectives'''
'''1.''' Learn each and every module as much as possible, in order to develop an overall product.
'''2.''' Understand the proper use of queues and semaphores in order to send/receive the data between multiple tasks.
'''3.''' Learn to integrate all modules and ensuring smooth transition, communication and context switching at desired time intervals.
'''4.''' Document and track all the bugs encountered during development and learn to update git repository after every fix.

== '''Team Members & Technical Responsibilities''' ==
[[File:cmpe244_F19_Infinity_Mirror_members.jpeg|thumb|500x500px|TEAM INFINITY MIRROR|right]]

*'''''[http://linkedin.com/in/aakash-chitroda-17841740 Aakash Chitroda]'''''
** MP3 Audio Encoder/Decoder
** Audio frequency Analyzer logic

*'''''[https://www.linkedin.com/in/ganeshram93 Ganesh Ram]'''''
** Interfacing of LED Matrix and driver design
** Game logic design
** Audio frequency spectrum logic on LED
** Packaging

*'''''[https://www.linkedin.com/in/niket-naidu-30090a134/ Niket Naidu]'''''
** Android & Bluetooth Application
** OLED Interfacing and Designing
** PCB Design improvements
** Accelerometer Sensor integration with OLED Screen

*'''''[https://www.linkedin.com/in/vidushi-jain-048b992a Vidushi Jain]'''''
** Bluetooth Communication
** Interfacing of Gesture & Accelerometer Sensors
** Hardware Designing & PCB Integration

 

== '''Administrative Responsibilities''' ==
{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|- style="vertical-align: top;"
! colspan="5" style="background:#588ecc" | Administrative Roles 
|-
! style="text-align: left;" |
* Team Lead 
| Aakash Chitroda 
|-
! style="text-align: left;" |
* Finance Manager
| Niket Naidu 
|-
! style="text-align: left;" |
* Git Repository Manager 
| Vidushi Jain 
|-
! style="text-align: left;" |
* Wiki Report Manager 
| Vidushi Jain 
 Ganesh Ram 
|-
! style="text-align: left;" |
* Bill of Materials Manager 
| Ganesh Ram 
|}

== '''Team Deliverables Schedule''' ==

{| class="wikitable"
|-
! scope="col" style="text-align: left;" style="background:#588ecc;" | WEEK
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
START DATE 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
END DATE 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
TASK DETAILS 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
STATUS 
|-
| 1 || 15 Oct 2019 || 22 Oct 2019 ||
*Create and establish GitLab repository
*Establish slack channel and invite Preet
*Look through previous years projects and study it
*Distribute major roles among team members
|| Completed Completed Completed Completed 
|-
| 2 || 23 Oct 2019 || 29 Oct 2019 ||
* Create a Bill of Materials 
* Select and order Parts 
* Review Data-sheet and Interfacing Of LED Matrix(Ganesh) 
* Review Data-sheet for Gesture sensor(Vidushi) 
* Make Repo on Gitlab for all modules - Follow Naming Convention. 
|| Completed Completed Completed Completed Completed 
|-
| 3 || 30 Oct 2019 || 5 Nov 2019 ||
* Review Data-sheet of Audio MP3 shield(Aakash) 
* Start Soldering for LED matrix and MP3 Shield 
* Start Soldering of Headers for MP3 Shield & decoder
* Environmental setup of Android & Web applications(Niket) 
* Implementation of Gesture Detection (Vidushi)
* Implementation of displaying text and basic shapes on LED Matrix (Ganesh)
|| Completed Completed Completed Completed Completed Completed 
|-
| 4 || 6 Nov 2019 || 12 Nov 2019 ||
* Implementation of OLED Driver(Niket)
* Initialization the Audio Decoder through SPI communication and read manufacturer ID 
* Implementation of random frequency bands on LED matrix (Ganesh)
* Implementation of communication Between two task(gesture_detect & LED_Display) using queues and semaphores (Vidushi)
* Display Gesture Sensor Directions on OLED in a Text (Vidushi & Niket)
* Read Song from SD Card 
|| Completed Completed Completed Completed Completed Completed 
|-
| 5 || 13 Nov 2019 || 19 Nov 2019 ||
* Circuit Simulation in Diptrace/Eagle Tool. 
* PCB Layout Design in Diptrace/Eagle Tool. 
* Finalize Components placement on PCB. 
* Read Song from SD Card and send to MP3 Shield 
* Receive Values from audio spectrum and send to display task to display on LED Matrix.(Aakash & Ganesh) 
* Interface OLED with onboard buttons to access the list of songs (Niket)
* Developing logic for the ball movement and translating hand-gesture control into LED movement.(Ganesh)
|| Completed Completed Completed Completed Completed Completed Completed 
|-
| 6 || 20 Nov 2019 || 26 Nov 2019 ||
* Interfacing of all modules sensors, bluetooth , MP3 and LED Matrix
* Test whole implementation after integration of all modules
* Test for stack overflow and system crash
* Debug and Test the Play/Pause/Stop functionality of MP3 player 
* Integrate fruit Fury game logic
* Update Final Wiki Schedule. 
|| Completed Completed Completed Completed Completed Completed Completed 
|-
| 8 || 27 Nov 2019 || 3 Dec 2019 ||
* Additional Feature week
* Establish Bluetooth communication of Device and Mobile APP 
* Develop UI on Android application. 
* Add Play/Pause/Stop and Song selection functionality to the APP. 
* Update Wiki with new details and information. 
* Enhanced game logic and integrated song play feature in game 
|| Completed Completed Completed Completed Completed 
|-
| 9 || 4 Dec 2019 || 10 Dec 2019 ||
* TESTING - CRITICAL WEEK 
* Packaging of hardware board and related components. 
* Check overall robustness of the complete system. 
* Establish complete connection on PCB 
* Update wiki with details. 
|| Completed Completed Completed Completed Completed 
|-
| 10 || 11 Dec 2019 || 17 Dec 2019 ||
* All hands on testing and final bug fixes. 
* Check for tuning or calibration of sensors if required. 
* Complete end-to-end testing for various scenarios and conditions. 
* Create the semester long project activity video and upload to YouTube. 
* Update and finalize wiki. 
|| Completed Completed Completed Completed Completed 
|-
| 11 || 18 Dec 2019 || ||
* '''DEMO: Final Project''' 
* '''SUBMISSION: Final Project Wiki''' 
|| Completed Completed 
|}

== '''Bill of Materials (General Parts)''' ==

{| class="wikitable"
|-
! scope="col" style="text-align: left;" style="background:#588ecc;" | PART NAME 

! scope="col" style="text-align: left;" style="background:#588ecc;" | 
PART MODEL & SOURCE 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
QUANTITY 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
COST PER UNIT (USD) 
|-
|
* Micro-Controller Eval-Boards
|
* LPC 4078 (Purchased from Preet Kang)
|
* 1
|
* 50.00

|-
|
* Audio decoder Breakout Board
|
* [https://www.sparkfun.com/products/12660 SparkFun MP3 Player Shield]
|
* 1
|
* 26.95

|-
|
* Audio Analyzer
|
* [https://www.amazon.com/dp/B074T9H8JV/ DFR0126 Audio Analyzer]
|
* 1
|
* 19.00

|-
|
* RGB LED matrix
|
* [https://www.sparkfun.com/products/14718 32 x 64 RGB LED Matrix Panel]
|
* 1
|
* 49.95

|-
|
* Power supply
|
* [https://www.sparkfun.com/products/15352 5V / 4A Power Supply]
|
* 1
|
* 12.95

|-
|
* Audio Speakers
|
* 3.5mm Jack Stereo Speakers
|
* 1
|
* Own

|-
|
* PCB parts and other Miscellaneous parts
|
* Anchor Electronics and Digikey '''
|
* 1
|
* 50.00

|-
|
* 2 way mirror
|
* [https://www.amazon.com/gp/product/B06Y2C79FC/ref=ppx_yo_dt_b_asin_title_o03_s00?ie=UTF8&psc=1 2-way mirror ]
|
* 1
|
* 7.64

|-
|
* PCB Fabrication
|
* [https://jlcpcb.com/quote JLCPCB]
|
* 5
|
* 29.53
|}

 

== '''Printed Circuit Board''' ==

=== Design And Architecture ===

We have designed the custom PCB using Eagle Software and as well as one prototype board in which we have connected all the modules with SJ-Two board. PCB was sent to fabrication to JLCPCB China which provided PCB with lead time of 1 week. We have implemented 2 layers of PCB with all of the parts in top layer.

'''Components Placements on PCB and on Prototype Board'''
'''1.''' One SJ-Two board is fitted onto the top of the 3D printed lid cover which with a slot opening for 2x40 IDC cable.
'''2.''' MP3 Decoder is connected with SJ-Two board and will be place on the right side of PCB and as well as on Prototype board.
'''3.''' Bluetooth Module needs only 4 pins to connect with SJ-Two and goes to UART3 and placed on the top left of the board.
'''4.''' LED Matrix is connected using 2x8 IDC cable pins on the top left side of the board.
'''5.''' Audio Frequency Analyzer is placed on the bottom side of PCB.
'''6.''' Power supply of 5v and 3.3v provisions are made on the bottom left side of PCB.

{|
[[File:Top_Layout.png|500x600px|thumb|left|Top Layer PCB Design On Eagle Software]]
|[[File:Bottom_Layout.png|500x600px|thumb|right|Bottom Layer PCB Design on Eagle Software]]
|}

{|
[[File:Top_View.png|500x600px|thumb|left|PCB Top Layer]]
|[[File:Bottom_View.png|500x600px|thumb|right|PCB Bottom Layer]]
|}

'''Infinity Mirror's Internal Circuit'''

[[File:Setup.jpeg|thumb|350x350px|center|Infinity Mirror: Internal Circuit of Embedded Entertainment Box]]

=='''Product Enclosure''' ==

To facilitate easy and convenient gaming experience and also act as an effective audio controller, a single 3D printed enclosure was designed which is spacious enough to accommodate the MCU modules like bluetooth, audio frequency analyzer and MP3 decoder on the PCB.

{|
|[[File:Top.jpeg|470px|thumb|left|Top View]]
|[[File:3D.png|430px|thumb|right|3D View]]
|}

===Final 3D Package===
[[File:Final_Setup.jpeg|thumb|600x600px|center|Infinity Mirror: Final Setup]]

=='''RGB LED Matrix'''==
A 32 x 64 RGB LED Matrix will be powered up through a 5V/4A DC adapter and is interfaced with the board to play the game 'Fruit Fury' with desired background song in the game-mode and to display the frequency bands and other relevant messages such as "Next", "Previous" and "Pause" in the music-mode. Only the INPUT IDC connector will be used because we are not cascading multiple matrices. The matrix has 2 planes (upper and lower), both of which will be programmed separately. In order to set RGB color data for each pixel in plane 1 (top half of the display) we use R1, G1 and B1 pins and for plane 2 we use R2, G2 and B2. By setting and resetting the CLOCK pulse, color data is set for every pixel in the row. Then the LATCH is set to mark end of the row and reset to move to next row. All of these steps are repeated at very less time intervals so that the human eye perceives it as one complete frame (Persistence of Vision).

Below is the description of the pins:

*R1 -> Sets upper panel's Red data
*G1 -> Sets upper panel's Green data
*B1 -> Sets upper panel's Blue data
*R2 -> Sets lower panel's Red data
*G2 -> Sets lower panel's Green data
*B2 -> Sets lower panel's Blue data
*A -> Sets row bit 0
*B -> Sets row bit 1
*C -> Sets row bit 2
*D -> Sets row bit 3
*CLK (Clock) -> Set to access each pixel
*LAT (Latch) -> Set to mark comletion of one row
*nOE (Output Enable) -> Set to switch the LEDs off when transitioning from one row to the next
*GND -> Ground pins to be connected with board's GND.

Below are the technical specifications:

*Pitch -> 4 mm
*Resolution -> 32 x 64 = 2048 dots
*Panel dimensions (l x b x h) in mm -> 256 x 128 x 13
*Working voltage/current rating -> 5v / 4A (max)
*Scan rate - 1/16
*Pixel component configuration (R,G,B) -> 1,1,1
*Weight -> 0.24 kg

=== Hardware Design ===
The hardware involves 5V/4A DC power supply adapter, barrel jack connectors and IDC cables to power up the LED matrix and communicate with the board. Below is the pin interfacing diagram.
[[File:Slide2.png|700x900px|thumb|center|LED Matrix Pin Diagram]]

=== Software Design ===
1. '''Fruit Fury - Game mode''' 

There are 2 tasks involved to ensure functioning of the game.

a) Task 1:
*Display the game's title screen. On pressing the onboard switch (SW1), game begins.
*Also used to display game over screen / win screen.
b) Task 2:
*Enter into game mode to play the game.
*Read accelerometer values (board orientation) and render game frame.
*Detect the player's board movement, compare it with fruit's location.
*Display score, lives and smash effects.
*Press another switch (SW0) to stop game and return to title screen or to restart the game once it is over.

 '''Game rules:''' 

a) Game comprises of 3 levels (level 2 on reaching score 15 and level 3 on reaching score 30) and 5 lives in total.

b) Primary objective is to tilt the board to the direction (North West, North East, South West or South East) in which the fruit appears in order to smash it.

c) Score increases by 1 point for smashing each fruit.

d) Bombs start appearing after completion of level 1, which costs a life when hit.

e) Level 3 is faster so make sure you tune your reflexes up.

f) Reach score 50 to win the game.

 '''Bonus:''' 

a) Streaks are rewarding. Smash 10 fruits straight up to win an extra life.

b) Look out for star fruits. Hit them to gain +2 points.

Choose your song to take all the inspiration you can and start smashing!

 '''2. Music mode''' 

a) Press the button to enjoy music-only mode. Graceful audio spectrum bands are displayed that dance to the tune of the chosen song.

b) A display is prompted to the user whenever music is paused or changed to next or previous song.

=== Implementation ===
'''LED Driver'''

1. Initialize the LED matrix by configuring necessary pin directions.

2. Disable Output Enable (OE) GPIO before feeding matrix data.

3. Select the required row by setting bits on A, B, C, D GPIO pins.

4. Loop through the pixels (columns) in the selected row and set the pixel color on R, G, B GPIO pins.

5. Set zero on R, G, B GPIO pins to mask that particular pixel.

6. Set and Reset the clock for pushing the R, G, B bits for each column.

7. Issue latch to mark the row's completion and reset latch before going to next row.

8. Follow the steps 2 to 7 for other rows.

<source lang="cpp">
for (uint8_t row = 0; row < (MAX_ROW / 2); row++) {
disableOE();
set_row(row);
for (uint8_t col = 0; col < MAX_COL; col++) {
LPC_GPIO0->PIN |= (1 << CLK);
set_color_bottom(game_matrix[row + (MAX_ROW / 2)][col]);
set_color_top(game_matrix[row][col]);
LPC_GPIO0->PIN &= ~(1 << CLK);
}
LPC_GPIO0->PIN |= (1 << LAT);
LPC_GPIO0->PIN &= ~(1 << LAT);
enableOE();
vTaskDelay(1);
}
</source>

'''Fruit Fury - Game mode'''

1. Generate the fruit's initial coordinate using random function (used srand() with time value as seed to get random pattern sets).

2. Construct the LED matrix array by drawing the fruit and borders.

3. Push the entire matrix data to LED driver to display the constructed matrix frame.

4. Then read the player's orientation and match with fruit's direction.

5. Modify game parameters (score, lives and level) based on player's results.

6. Stop game if all lives are over and display game over screen by switching to game init task (Task 1).

<source lang="cpp">
/* Push button to exit game */
if (LPC_GPIO0->PIN & (1 << SW0))
is_start_game = false;

if (is_start_game == true) {
/* Generate fruit's initial coordinate position */
get_fruit_begin_coord(&row_pt, &col_pt, &quadrant);
/* Generate final frame by considering fruit object at that position */
construct_game_matrix(row_pt, col_pt);
/* Draw final frame matrix of the game */
draw_final_game_frame();
/* Get the board direction from the user and increment score count */
compute_game_params(row_pt, col_pt, quadrant);
} else
vTaskResume(display_game_init_screen_t);
</source>

'''Spectrum display - Music mode'''

1. Read the audio frequency values from the graphic equalizer task and store it as an array.

2. Based on value of each frequency band, assign a height of the band (in pixels) to be drawn on the LED matrix.

3. Set a unique color for each band.

3. Push the entire matrix data to LED driver to display the constructed matrix frame.

4. Repeat steps 1 to 3 at required intervals to display repeating bands.

<source lang="cpp">

for (row = MAX_ROW - 1; row >= 1; row--) {
for (col = 7; col <= 62; col++) {
if ((row >= (MAX_ROW - band_height[0])) && col >= 7 && col <= 13 &&
band_num <= 0) {
band_matrix[row][col] = RED;
}
if ((row >= (MAX_ROW - band_height[1])) && col >= 14 && col <= 20 &&
band_num <= 1) {
band_matrix[row][col] = GREEN;
}
if ((row >= (MAX_ROW - band_height[2])) && col >= 21 && col <= 27 &&
band_num <= 2) {
band_matrix[row][col] = YELLOW;
}
if ((row >= (MAX_ROW - band_height[3])) && col >= 28 && col <= 34 &&
band_num <= 3) {
band_matrix[row][col] = BLUE;
}
if ((row >= (MAX_ROW - band_height[4])) && col >= 35 && col <= 41 &&
band_num <= 4) {
band_matrix[row][col] = PURPLE;
}
if ((row >= (MAX_ROW - band_height[5])) && col >= 42 && col <= 48 &&
band_num <= 5) {
band_matrix[row][col] = CYAN;
}
if ((row >= (MAX_ROW - band_height[6])) && col >= 49 && col <= 55 &&
band_num <= 6) {
band_matrix[row][col] = WHITE;
}
}
}

</source>

=='''MP3 Decoder'''==

The Audio Decoder breakout board communicates with the SJ board over SPI and is interfaced with the SPI-0 pins of the SJ board as follows:

*Clock Pin (Pin 13) - SJ SPI-0 Clock Pin
*MISO Pin (Pin 12) - SJ SPI-0 MISO Pin
*MOSI Pin (Pin 11) - SJ SPI-0 MOSI Pin
*MP3 CS: Chip Select Pin for the audio decoder to be activated while sending control signals.
*MP3 DCS: Chip Select Pin for the audio decoder to be activated while sending audio data signals.
*MP3 RST: Reset pin for the audio decoder.
*MP3 DREQ: Data Request Pin. Audio decoder signals that it is ready to accept next 32 bytes of audio data.
*VCC pin - SJ 3.3V pin
*GND pin - SJ GND Pin

=== Hardware Design ===
[[File:Slide1.png|800x900px|thumb|center|MP3 Decoder Pin Diagram]]

=== Software Design ===

[[File:Mp3_fLow.png|600x500px|thumb|center|MP3 Decoder Software Design]]

=== Implementation ===

We are interfacing MP3 Decoder on the SPI0 for reading the Audio Mp3 file from the SDCard and send Mp3 data to the Decoder. The purpose of this task is to send mp3 data to the mp3 decoder. This is a high priority as it is acting as a consumer. The producer task in our project is the task that reads songs that fill the freeRTOS queue with 4KB of data. The consumer task i.e the task that sends a song to the mp3 decoder that waits on an empty queue for portMAX_DELAY. Once the queue has data, the task starts sending 32 bytes at a time to the MP3 decoder. Once 32 bytes are sent, the task waits for the DREQ pin to get high. DREQ pin high indicates that the MP3 decoder unit is ready to take 32 bytes of data. For sending data, the task acquires the MUTEX so that no other task can use the SPI bus at the same time. Once the 32 bytes are sent, the MUTEX is released. This is the working of the task.

// Task to send data to decoder(High priority)
static uint8_t bytes_to_be_sent_to_decoder[READ_BYTES_FROM_FILE];
static uint8_t current_count = 0;
uint32_t start = 0, end = 0;
while (1) {
if (0 == current_count) {
xQueueReceive(mp3_queue, &bytes_to_be_sent_to_decoder[0], portMAX_DELAY);
}
start = (current_count * TRANSMIT_BYTES_TO_DECODER);
end = ((current_count + 1) * TRANSMIT_BYTES_TO_DECODER);
while (!mp3__dreq_get_status()) {
mp3__decoder_refresh();
vTaskDelay(2);
}
if (xSemaphoreTake(mp3_mutex, portMAX_DELAY)) {
mp3__data_cs();
send_32_bytes_to_decoder_using_ssp(start, end,
&bytes_to_be_sent_to_decoder[0]);
mp3__data_ds();
xSemaphoreGive(mp3_mutex);
if (current_count == COUNT - 1) {
current_count = start = end = 0;
} else {
current_count += 1;
}}}

=='''Audio Frequency Analyzer'''==

In the audio analyser, strobe and reset pins are used to select the DC peak output. Reset high resets the multiplexer. Reset low enables the strobe pin. At the leading edge of the first strobe, the first frequency band 63Hz is on the output. On each additional leading edge strobe the next frequency band(160Hz, 400Hz, 1kHz, 2.5kHz, 6.25kHz, 16kHz) is detected.

This analyser takes input from Audio decoder for left and right side music. SJ2 controls the RS and ST pins of the "Audio Frequency Analyzer" and reads input data from S pin which is connected to ADC pin (P0.26) of SJ2 board.

*Audio Analyzer S pin -> SJ2 ADC4 pin
*Audio Analyzer RS pin -> SJ2 P0.11 pin
*Audio Analyzer ST pin -> SJ2 P2.0 pin
*Audio Analyzer + pin -> SJ2 VCC pin
*Audio Analyzer - pin -> SJ2 GND pin
<div style="clear: both"></div>

====Audio Frequency Analyser====
Audio frequency analyser is working is most important task in order to get correct value. Incorrect initialisation and in efficient delays may cause error. In this project Init and reading of data at each frequncy band is implemented based on timing diagram shown as bellow:

[[File:244 Spark TimingDiagram AudioAnalyser.jpeg|thumb|550x400px|centre|Timing Diagram of Audio Analyser]]

The software Implementation to Init frequency analyser is as follow: 
1. Select ADC pin 
2. Select GPIO pin direction for reset pin and STOBE pin 
3. Reset Audio frequency analyser 

=='''Sensors Interface'''==

We have worked on two sensors for accessing our entertainment box i.e. Gesture Sensor and Accelerometer. The SJ-Two board has both sensors on board sensor which is interfaced on the I2C bus. Accelerometers are electromechanical devices that sense either static or dynamic forces of acceleration. Static forces include gravity, while dynamic forces can include vibrations and movement. The measurements are on 3-axis and these values can be calibrated to find the desired values.

In our project, an accelerometer is for controlling Controls in the MP3 Mode like PLAY,PAUSE,PLAY Next Song and Back to Previous Song.However in Game Mode we are playing our fruit fury game using Orientation sensor for Smashing fruits coming in Directions South East, South West ,North East and North West and We were using Gesture on SJ-Two Board for gesture recognitions Left, Right, UP and Down to change the configuration in MP3 Mode but after implementation we have realised that giving gesture is more complicated then getting signals from orientation.

=== Hardware Design ===

[[File:Sensor.png|800x900px|thumb|center|APDS9960 & MMA8452Q on board Sensors]]

=== Software Design ===

[[File:Sensor_FLow.png|600x500px|thumb|center|MMA8452Q Software Design]]

=== Implementation ===
The MMA8452Q has an orientation detection algorithm with the ability to detect all six orientations but we are using only 4 orientations i.e. Portrait Up, Portrait Down,Landscape Left and Landscape Right .The transition from portrait to landscape is fixed with a 45° threshold angle and a ±14° hysteresis angle. This allows the for a smooth transition from portrait to landscape at approximately 30° and then from landscape to portrait at approximately 60°.

[[File:accel_orient.png|800x900px|thumb|center|Portrait Orientation]]

We have used the following register settings to configure the sensors and getting all 4 directions and Orientation.

[[File:APDS_Register.png|800x900px|thumb|center|Registers of APDS9960]]

 

After reading the registers we are just performing the actions as per the Orientation detected.

[[File:Accel_register.png|800x900px|thumb|center|Registers of MMA8452Q]]

 

void perform_action_on_orientation(void *p)
{
orientation_e value;
while (1)
{
value = GetOrientation();
switch (value)
{
case Portrait_UP: // Prev Song
printf("Direction Left\n");
xSemaphoreGive(sem__prev_song);
break;
case Portrait_DOWN: // Next Song
printf("Direction Right\n");
xSemaphoreGive(sem__next_song);
break;
case Landscape_LEFT: // Resume/Play/
printf("Direction Up\n");
vTaskSuspend(handle__play_song);
vTaskSuspend(handle__freq_bands);
song_status = PLAY;
break;
case Landscape_RIGHT: // Pause/Stop/Volume Decrease
printf("Direction Down\n");
vTaskResume(handle__play_song);
vTaskResume(handle__freq_bands);
song_status = PAUSE;
break;
default:
break;
}
vTaskDelay(50);
}}

=='''Bluetooth Interface'''==
The SJ-two is connected to the Bluetooth module through the Serial interface (UART3) and we have configured it at 38400 baud rate with 8-bit data and 1 stop bit using the Communication Mode. It is used to send and receive the Game and Music data from our entertainment device to an android application.

=== Hardware Design ===

[[File:Slide3.png|700x900px|thumb|center|Bluetooth Interface Pin Diagram]]

===HC-05 Bluetooth module===
HC-05 Bluetooth Module is used to set up wireless communication between the entertainment device and the Android phone. The right section of the Bluetooth Board has connection pins for power and signals as well as a 5V to 3.3V Regulator, LED, and level shifting.

'''HC-05 PinOut'''
* EN: N/A
* VCC: 5V Power
* GND: Ground
* TXD: Serial Transmit pin connected to RXD3 of SJ board
* RXD: Serial Receive pin connected to TXD3 of SJ board
* STATE: States if connected or not

=== Software Design ===

[[File:Bluetooth_Sw_diagram.png|600x500px|thumb|center|Bluetooth Software Design]]

=== Implementation ===

An accelerometer is used in the MP3 Mode to implement functionalities such as play, pause, switch to next and previous songs and volume control. In the game mode the “Fruit fury” game is played by smashing fruits appearing in the directions South East, South West, North East and North West. UART3 is used as communication protocol.The Bluetooth commands that we are using to interact with Mobile app and Device are as follows:

GAMING = 0xA1,
NORTH_EAST = 0x71,
NORTH_WEST = 0x72,
SOUTH_WEST = 0x73,
SOUTH_EAST = 0x74,
MUSIC = 0xA2,
SONG_LIST = 0xA3,
NEXT_SONG = 0xC2,
TOGGLE_SONG = 0xC1,
PREV_SONG = 0xC0,
ACK = 0x00,
NACK = 0xFF,
VOL_INC = 0xB1,
VOL_DEC = 0xB0

=='''Mobile Application'''==

{|
|[[File:Modes.jpeg|230px|thumb|List Of Feature in the APP]]
|[[File:GAME.jpeg|230px|thumb|Game Mode]]
|[[File:Mp3_song.jpeg|230px|thumb|MP3 Mode]]
|[[File:SongList.jpeg|230px|thumb|List Of Songs in SD Card]]
|}

=== Software Design ===

The Android app has been built using the cross platform framework [https://flutter.dev/ Flutter]

The app is composed of 3 parts, '''Game Mode''', '''MP3 Mode''' and '''MP3 Song List'''. On the main screen we first connect to the bluetooth before establishing connection with any of the modes. The working of each mode is explained in each subsection below.

A few variables to note in advance
ACK = 0x00, sent when successful
NACK = 0xFF, sent incase there is any error

====1. Game Mode ====

Wireless communication with the Entertainment box communication over Bluetooth protocol. Android Application is created which provides an interface to exchange data and configure the device.To enter the Game Mode screen we first check if the Bluetooth Connection is established. We send in a one byte data 0xa1 over bluetooth to the SJ2 Board and get back the response "a1$ack/nack$##" We then enter the game mode which displays a joystick that can be oriented to a direction wherever the fruit appears on the LED matrix. The corresponding orientation value is then transmitted.If the fruit had appeared in any of the quadrant then will send data from BLE APP to SJTwo Board.

'''1.''' First Quadrant (North-East): 0x71 
'''2.''' Second Quadrant (North-West): 0x72 
'''3.''' Third Quadrant (South-West): 0x73 
'''4.''' Fourth Quadrant (South-East): 0x74 

====2. MP3 Mode ====

To enter the MP3 Mode screen we first check if the Bluetooth Connection is established similar to the Game Mode. We send in one byte of data 0xa2 over bluetooth to the SJ2 Board and get back the response "a2$ack/nack$volumeInfo$currentSong$isPlaying/isPaused$##" where isPlaying is 1 and isPaused is 0. These values are loaded into the MP3 Mode Screen as initial values for the current song playing. We can then see a screen where we can control the various aspects of playing songs i.e Playing and Pausing the song, Go to next song and and Go to the previous song. We can also control the volume remotely.Controlling each part of this interface is the same as sending a single byte of data over bluetooth to the SJ2 Board.

'''1.''' Playing and Pausing Song - We just toggle the state of the Song. We issue this command by sending 0xc1 which is the Toggle State command. 
'''2.''' Next Song and Previous Song - Command for the previous and next song is 0xC0 and 0xC2. 
'''3.''' Control Volume remotely - For volume we divide the percentage 100 percent in 16 parts. We can send the value between 0xb0 to 0xbf in increments of one step. This is parsed on the SJ2 Board and converted to an equivalent volume signal. 

====3. MP3 Song List ====
To get the list of MP3 Songs which are present in the SD card, we first check if the Bluetooth Connection is established similar to the Game Mode and MP3 Song mode. We send in one byte of data 0xa3 over bluetooth to the SJ2 Board and get back the response "a3$ack/nack$data$data$...$##". APIs that were designed to read song information and data by Audio Decoder, will be used for achieving this functionality.

=='''OLED Screen'''==

[[File:Oled_screen.jpeg|thumb|600x600px|center|Oled Screen Functionality]]

=== Software Design ===

The open source package [https://github.com/olikraus/u8g2 u8g2] has been used.
There are already ready made functions for various OLED Drivers. The indepth setup guide can be found [https://github.com/olikraus/u8g2/wiki/u8g2setupc here]

=== Implementation ===

The u8g2 library is a very robust library which means that this code can be extended for any microcontroller as long as the interface is written properly.

We needed to write 2 main functions, outlined below, i.e byte_cb and gpio_and_delay_cb using the function prototype `uint8_t u8x8_lpc_gpio_and_delay(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr)`.

Since the SJ2 Board is connected to the OLED Screen on the SPI1 Bus we also need to write the SPI1 driver, mainly a method to that sends data over SPI to the Slave device i.e the OLED Screen

=== Initializing the u8g2 for LPC4078 ===

<source lang="cpp">

// Created a file `u8g2_wrapper.h

static gpio_s dc;
static u8g2_t u8g2;

void u8g2_wrapper__init(gpio_s *dc_pin) {
u8g2_Setup_ssd1306_128x64_vcomh0_1(&u8g2, U8G2_R0, u8x8_byte_4wire_hw_spi, u8x8_lpc_gpio_and_delay);
u8g2_InitDisplay(&u8g2);
u8g2_SetPowerSave(&u8g2, 0);

dc.pin_number = dc_pin->pin_number;
dc.port_number = dc_pin->port_number;
}

u8g2_t *u8g2_wrapper__get_instance() { return &u8g2; }

uint8_t u8x8_lpc_gpio_and_delay(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr) {
switch (msg) {
case U8X8_MSG_GPIO_AND_DELAY_INIT:
delay__ms(1);
break;
case U8X8_MSG_DELAY_MILLI:
delay__ms(arg_int);
break;
case U8X8_MSG_GPIO_DC:
// DONE, Write to the GPIO_DC Pin
if (arg_int == 0) {
gpio__reset(dc);
} else {
gpio__set(dc);
}
break;
case U8X8_MSG_GPIO_RESET:
break;
}
return 1;
}

uint8_t u8x8_byte_4wire_hw_spi(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr) {
uint8_t *data;
switch (msg) {
case U8X8_MSG_BYTE_SEND:
data = (uint8_t *)arg_ptr;
while (arg_int > 0) {
ussp1__exchange_byte((uint8_t)*data);
data++;
arg_int--;
}
break;
case U8X8_MSG_BYTE_INIT:
break;
case U8X8_MSG_BYTE_SET_DC:
if (arg_int == 0) {
gpio__reset(dc);
} else {
gpio__set(dc);
}
break;
case U8X8_MSG_BYTE_START_TRANSFER:
break;
case U8X8_MSG_BYTE_END_TRANSFER:
break;
default:
return 0;
}
return 1;
}

</source>

=='''Technical Challenges'''==

1. '''RGB LED Matrix''' 

* Getting control of the matrix was challenging as it needs to follow specific sequence of pin enabling/disabling at appropriate timing.

* Setting right delays to avoid flickers and get smooth transitioning between frames by using delays or for loops.

* Fixing high CPU utilization by changing delay__us to vTaskDelay.

* Designing elements of the game (title screen and fruit objects) which required careful plotting of pixel data.

2. '''Audio Decoder''' 

a) The CPU utilization for sending a song task was very high (80% +).
* In order to reduce the utilization, we gave the vTaskDelay(1) while waiting for the DREQ to be high. The high DREQ indicates that the decoder is ready to receive next 32 bytes of data. So meanwhile, when the DREQ pin is low, we made task to sleep for vTaskDelay(1). After doing this, we significantly reduced the CPU utilization to 15%. We tried with vTaskDelay(2) to get CPU utilization of 10%.
* We further tried to make the CPU utilization below 10%. This was really a tough challenge, and figured out that the actual SPI clock is 1Mhz which is too slow as SPI is meant to operate at much higher speed. We changed the clock rate of SPI to 12MHz but the song speed was too slow. We checked the datasheet of the Mp3 decoder and set the internal clock multiplier to 4.5x. This make the shield operate at high clock rates at 12.XX Mhz. So keeping this in mind we made the SPI speed to 12MHz which is safe. We successfully achieved CPU utilization of 5-6% which is very much in the acceptable range.

3. '''PCB Designing''' 

* We realized that using GPP for long term is not a good idea. Initially we spent time in debugging our hardware and later we have realized like we can’t take this for our final day.
* We did multiple reviews before ordering our final PCB as none of us did that earlier. We have faced issue in manual routing on Eagle Autodesk but our ISA Prashant helped us and he reviewed our PCB design twice.

4. '''Mobile Application''' 

* The main challenge of the Mobile application was to make the UI interactive while getting data asynchronously over the Bluetooth module.
* There was a global listener stream implemented that got the value and concatenate the string till we received the end frame (##).
* However the challenge still existed to know which screen has called what data which prompted us to create the key and ACK/NACK pair in the start.
* The Mobile app is completely data reactive, which means that the UI components render and change according to the data provided. This caused a lot of issues mainly since we tried polling methods to make sure that the UI remains up to date with the STATE of the SJ2 Board.
* A manual approach was opted for mainly to make the system more deterministic and for better debugging capabilities.

=='''Suggestions for Future Students'''==
 '''RGB LED Matrix''' 

* To begin with, focus on writing a simple driver to get control of 1 pixel at a targeted location and then use appropriate loops to light up the entire row/column.

* Make sure all pixels are able to light up with all possible colors to eliminate hardware defects.

* Try with minimum / no delays, print tick counts and then come up with meaningful delay numbers.

* Optimize the code (minimum delays, avoiding repetitive function calls, etc.) to bring down the CPU usage level.

* Use the link in the references to draw desired elements and generate the matrix.

 '''Tips for getting GOOD Grades and to remain in top 3 teams''' 
* Select your teammates wisely, and make sure every one dedicates themself for this project.
* Be an active member of your team and review rubrics for the final DEMO.
* As soon as the professor mentions the project, please start working on the project otherwise, in the end, you have to struggle with finals and you will be left with less time for testing and you have to struggle in demo.

 '''General tips''' 
* Remember the KISS approach when you code. (Keep It Simple and Stupid).
* For this project, one should know the basics in C/ C++, FreeRTOS, and some good debugging skills. Because if you don't have one, you will eventually end up spending more time debugging your problem.
* Always give meaningful names to the variable or the function, so a third person reviewing the code gets an overall idea by just reading the name.

=='''Conclusion'''==
It was a really great working experience for all of us. We were really thrilled from the beginning that we will be working on something that is quite relevant in the industries. We worked as a team of four which helped us all to know the importance of team-work and co-ordination. We learned many great stuff like

* State Design using FreeRTOS
* FreeRTOS APIS when task handles are NULL vs when Initialised.
* Uses of extern and global variables as opposed to encapsulation i.e static inside private 'c' files.
* Learning Optimization through the integration of our peer's individual modules
* Improving CPU utilisation of the main LED and MP3 tasks.
* Workload sharing and cooperation amongst peers.
* Sharing ideas and debugging a common problem together i.e team building.
* We realised that using GPP for long term is not a good idea, there were some breakdown in the wires and our MP3 stopped working. Initially we spent a lot of time debugging hardware and doing soldering. So we started designing the PCB, and when our PCB was done, we spent hardly any time debugging the hardware.
* Git : We learnt all the basic of GIT and it plays an important to role for source code versioning.

There were a lot of problems while doing this project but it was a steep learning curve. In the end we were able to achieve our objective with really good results.

=='''Project Video'''==
https://youtu.be/vVjHCoyWYz4

=='''Project Source Code'''==
* Git Project Link (Individual Modules): [https://gitlab.com/Infinity_Mirror/infinity_mirror-cmpe-244]
* Git Project Link: [https://gitlab.com/ganeshram2493/infi_mirror]

=='''Project Presentation File'''==
* [https://drive.google.com/file/d/1Q_Xvs-a2feQcr-FbPEKbwmlhi35hqNxX/view?usp=sharing Presentation Link]

=='''References'''==
=== Acknowledgement ===

We would like to express our gratitude to Professor Preetpal Kang for generously sharing his time and knowledge with us and guiding us through the completion of this project. We would also like to thank the Prashant Gandhi(ISA) for their valuable advice and constructive feedback.

=== References Used ===

====== Flutter Android GUI ======
* [https://material.io/resources/icons/?style=baseline Material Design Icons]
* [https://flutter.dev/ Building a Dynamic UI with Flutter]
* [https://www.youtube.com/channel/UCwXdFgeE9KYzlDdR7TG9cMw Flutter Youtube Channel]

====== RGB LED Matrix Interfacing and Designing ======
* [https://www.sparkfun.com/products/14718 Datasheet and Hookup guide]
* [https://cdn-learn.adafruit.com/downloads/pdf/32x16-32x32-rgb-led-matrix.pdf?timestamp=1543806512/ Wiring and pin information]
* [https://www.riyas.org/2013/12/online-led-matrix-font-generator-with.html Hex code generator to build LED matrix models]

====== MP3 Decoder and Frequency Analyzer ======
* [https://www.sparkfun.com/datasheets/Components/General/MSGEQ7.pdf Seven Band Graphic Equalizer MSGEQ7 Data Sheet]
* [https://www.kr4.us/SparkFun-MP3-Player-Shield.html?gclid=EAIaIQobChMIov3f7PWc2wIVDtVkCh0-rgStEAYYASABEgIEgPD_BwE SparkFun-MP3-Player-Shield Datasheet]

====== Gesture & Orientation Sensors ======
* [https://cdn.sparkfun.com/assets/learn_tutorials/3/2/1/Avago-APDS-9960-datasheet.pdf Gesture Sensor Data Sheet]
* [https://learn.sparkfun.com/tutorials/mma8452q-accelerometer-breakout-hookup-guide/all Accelerometer Sensor Data]

====== General/Miscellaneous ======
* [http://socialledge.com/sjsu/index.php/FreeRTOS_Tutorial FreeRTOS Tutorial]
* [https://sjsu-dev2.readthedocs.io/en/latest/?badge=latest SJTwo-c Documentation]

F19: Infinity Mirror

2019-12-18T23:35:42Z

Proj user22: /* OLED Screen */

== '''Abstract''' ==

The main theme of the project is to build an interactive embedded system consisting of two entertainment modes - Music and Gaming. On the music mode, the MP3 decoder module reads songs from an SD card on the MCU board and plays the music through a speaker. It deals with the convergence of various services such as playing a game with background music, control volume, switch and pause/play songs. While the song is being played, audio frequency spectrum bands based on music tune are displayed on the LED Matrix band visualization etc. On the game mode, a fruit smashing game called “Fruit Fury” is implemented where the user needs to orient the MCU board in a direction according to where the fruit appears on the LED matrix. Alongside, the user can listen and switch songs. To achieve the above functionalities, various elements such as Audio Decoder, Audio frequency analyzer, 32x64 RGB LED Matrix and HC-05 bluetooth module and Android application are integrated.

[[File:High_level1.png|800px|thumb|center|Block Diagram of Infinity Mirror]]

== '''Introduction & Objectives''' ==

The key features supported by the system is real-time orientation recognition & trigger respective actions in 2 modes - MP3 mode and Game mode.

MP3 MODE:

1. Determine the accelerometer sensor values based on the orientation of the board and perform music control such as play, pause, volume control and changing songs.

2. In response, retrieve the data from the SD Card & communicate to the audio decoder for appropriate audio streaming.

3. Also implemented interaction with HC-05 bluetooth module through a customized mobile application and provide same operations.

4. Display frequency spectrum bands in sync to the tune of the song played.

GAME MODE - Fruit Fury:

1. Determine the accelerometer sensor values based on the orientation of the board and hit the fruit in corresponding direction.

2. Incorporating provision on the board's switches to change to next or previous song.

3. Also implemented interaction with HC-05 bluetooth module through a customized mobile application and play the game through the same.

'''Project Objectives'''
'''1. Audio Decoder''' - Fetches song data from the SD card and plays it over a speaker.
'''2. RGB LED Matrix''' - Display frequency bands on music mode or view the game on game mode.
'''3. Audio Frequency Analyzer''' - To convert the audio data into 7 spectrum bands which is then displayed as individual colored bands on the LED matrix.
'''4. Bluetooth HC-05''' - Interfaces the system using Bluetooth to an Android application.

'''Team Objectives'''
'''1.''' Learn each and every module as much as possible, in order to develop an overall product.
'''2.''' Understand the proper use of queues and semaphores in order to send/receive the data between multiple tasks.
'''3.''' Learn to integrate all modules and ensuring smooth transition, communication and context switching at desired time intervals.
'''4.''' Document and track all the bugs encountered during development and learn to update git repository after every fix.

== '''Team Members & Technical Responsibilities''' ==
[[File:cmpe244_F19_Infinity_Mirror_members.jpeg|thumb|500x500px|TEAM INFINITY MIRROR|right]]

*'''''[http://linkedin.com/in/aakash-chitroda-17841740 Aakash Chitroda]'''''
** MP3 Audio Encoder/Decoder
** Audio frequency Analyzer logic

*'''''[https://www.linkedin.com/in/ganeshram93 Ganesh Ram]'''''
** Interfacing of LED Matrix and driver design
** Game logic design
** Audio frequency spectrum logic on LED
** Packaging

*'''''[https://www.linkedin.com/in/niket-naidu-30090a134/ Niket Naidu]'''''
** Android & Bluetooth Application
** OLED Interfacing and Designing
** PCB Design improvements
** Accelerometer Sensor integration with OLED Screen

*'''''[https://www.linkedin.com/in/vidushi-jain-048b992a Vidushi Jain]'''''
** Bluetooth Communication
** Interfacing of Gesture & Accelerometer Sensors
** Hardware Designing & PCB Integration

 

== '''Administrative Responsibilities''' ==
{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|- style="vertical-align: top;"
! colspan="5" style="background:#588ecc" | Administrative Roles 
|-
! style="text-align: left;" |
* Team Lead 
| Aakash Chitroda 
|-
! style="text-align: left;" |
* Finance Manager
| Niket Naidu 
|-
! style="text-align: left;" |
* Git Repository Manager 
| Vidushi Jain 
|-
! style="text-align: left;" |
* Wiki Report Manager 
| Vidushi Jain 
 Ganesh Ram 
|-
! style="text-align: left;" |
* Bill of Materials Manager 
| Ganesh Ram 
|}

== '''Team Deliverables Schedule''' ==

{| class="wikitable"
|-
! scope="col" style="text-align: left;" style="background:#588ecc;" | WEEK
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
START DATE 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
END DATE 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
TASK DETAILS 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
STATUS 
|-
| 1 || 15 Oct 2019 || 22 Oct 2019 ||
*Create and establish GitLab repository
*Establish slack channel and invite Preet
*Look through previous years projects and study it
*Distribute major roles among team members
|| Completed Completed Completed Completed 
|-
| 2 || 23 Oct 2019 || 29 Oct 2019 ||
* Create a Bill of Materials 
* Select and order Parts 
* Review Data-sheet and Interfacing Of LED Matrix(Ganesh) 
* Review Data-sheet for Gesture sensor(Vidushi) 
* Make Repo on Gitlab for all modules - Follow Naming Convention. 
|| Completed Completed Completed Completed Completed 
|-
| 3 || 30 Oct 2019 || 5 Nov 2019 ||
* Review Data-sheet of Audio MP3 shield(Aakash) 
* Start Soldering for LED matrix and MP3 Shield 
* Start Soldering of Headers for MP3 Shield & decoder
* Environmental setup of Android & Web applications(Niket) 
* Implementation of Gesture Detection (Vidushi)
* Implementation of displaying text and basic shapes on LED Matrix (Ganesh)
|| Completed Completed Completed Completed Completed Completed 
|-
| 4 || 6 Nov 2019 || 12 Nov 2019 ||
* Implementation of OLED Driver(Niket)
* Initialization the Audio Decoder through SPI communication and read manufacturer ID 
* Implementation of random frequency bands on LED matrix (Ganesh)
* Implementation of communication Between two task(gesture_detect & LED_Display) using queues and semaphores (Vidushi)
* Display Gesture Sensor Directions on OLED in a Text (Vidushi & Niket)
* Read Song from SD Card 
|| Completed Completed Completed Completed Completed Completed 
|-
| 5 || 13 Nov 2019 || 19 Nov 2019 ||
* Circuit Simulation in Diptrace/Eagle Tool. 
* PCB Layout Design in Diptrace/Eagle Tool. 
* Finalize Components placement on PCB. 
* Read Song from SD Card and send to MP3 Shield 
* Receive Values from audio spectrum and send to display task to display on LED Matrix.(Aakash & Ganesh) 
* Interface OLED with onboard buttons to access the list of songs (Niket)
* Developing logic for the ball movement and translating hand-gesture control into LED movement.(Ganesh)
|| Completed Completed Completed Completed Completed Completed Completed 
|-
| 6 || 20 Nov 2019 || 26 Nov 2019 ||
* Interfacing of all modules sensors, bluetooth , MP3 and LED Matrix
* Test whole implementation after integration of all modules
* Test for stack overflow and system crash
* Debug and Test the Play/Pause/Stop functionality of MP3 player 
* Integrate fruit Fury game logic
* Update Final Wiki Schedule. 
|| Completed Completed Completed Completed Completed Completed Completed 
|-
| 8 || 27 Nov 2019 || 3 Dec 2019 ||
* Additional Feature week
* Establish Bluetooth communication of Device and Mobile APP 
* Develop UI on Android application. 
* Add Play/Pause/Stop and Song selection functionality to the APP. 
* Update Wiki with new details and information. 
* Enhanced game logic and integrated song play feature in game 
|| Completed Completed Completed Completed Completed 
|-
| 9 || 4 Dec 2019 || 10 Dec 2019 ||
* TESTING - CRITICAL WEEK 
* Packaging of hardware board and related components. 
* Check overall robustness of the complete system. 
* Establish complete connection on PCB 
* Update wiki with details. 
|| Completed Completed Completed Completed Completed 
|-
| 10 || 11 Dec 2019 || 17 Dec 2019 ||
* All hands on testing and final bug fixes. 
* Check for tuning or calibration of sensors if required. 
* Complete end-to-end testing for various scenarios and conditions. 
* Create the semester long project activity video and upload to YouTube. 
* Update and finalize wiki. 
|| Completed Completed Completed Completed Completed 
|-
| 11 || 18 Dec 2019 || ||
* '''DEMO: Final Project''' 
* '''SUBMISSION: Final Project Wiki''' 
|| Completed Completed 
|}

== '''Bill of Materials (General Parts)''' ==

{| class="wikitable"
|-
! scope="col" style="text-align: left;" style="background:#588ecc;" | PART NAME 

! scope="col" style="text-align: left;" style="background:#588ecc;" | 
PART MODEL & SOURCE 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
QUANTITY 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
COST PER UNIT (USD) 
|-
|
* Micro-Controller Eval-Boards
|
* LPC 4078 (Purchased from Preet Kang)
|
* 1
|
* 50.00

|-
|
* Audio decoder Breakout Board
|
* [https://www.sparkfun.com/products/12660 SparkFun MP3 Player Shield]
|
* 1
|
* 26.95

|-
|
* Audio Analyzer
|
* [https://www.amazon.com/dp/B074T9H8JV/ DFR0126 Audio Analyzer]
|
* 1
|
* 19.00

|-
|
* RGB LED matrix
|
* [https://www.sparkfun.com/products/14718 32 x 64 RGB LED Matrix Panel]
|
* 1
|
* 49.95

|-
|
* Power supply
|
* [https://www.sparkfun.com/products/15352 5V / 4A Power Supply]
|
* 1
|
* 12.95

|-
|
* Audio Speakers
|
* 3.5mm Jack Stereo Speakers
|
* 1
|
* Own

|-
|
* PCB parts and other Miscellaneous parts
|
* Anchor Electronics and Digikey '''
|
* 1
|
* 50.00

|-
|
* 2 way mirror
|
* [https://www.amazon.com/gp/product/B06Y2C79FC/ref=ppx_yo_dt_b_asin_title_o03_s00?ie=UTF8&psc=1 2-way mirror ]
|
* 1
|
* 7.64

|-
|
* PCB Fabrication
|
* [https://jlcpcb.com/quote JLCPCB]
|
* 5
|
* 29.53
|}

 

== '''Printed Circuit Board''' ==

=== Design And Architecture ===

We have designed the custom PCB using Eagle Software and as well as one prototype board in which we have connected all the modules with SJ-Two board. PCB was sent to fabrication to JLCPCB China which provided PCB with lead time of 1 week. We have implemented 2 layers of PCB with all of the parts in top layer.

'''Components Placements on PCB and on Prototype Board'''
'''1.''' One SJ-Two board is fitted onto the top of the 3D printed lid cover which with a slot opening for 2x40 IDC cable.
'''2.''' MP3 Decoder is connected with SJ-Two board and will be place on the right side of PCB and as well as on Prototype board.
'''3.''' Bluetooth Module needs only 4 pins to connect with SJ-Two and goes to UART3 and placed on the top left of the board.
'''4.''' LED Matrix is connected using 2x8 IDC cable pins on the top left side of the board.
'''5.''' Audio Frequency Analyzer is placed on the bottom side of PCB.
'''6.''' Power supply of 5v and 3.3v provisions are made on the bottom left side of PCB.

{|
[[File:Top_Layout.png|500x600px|thumb|left|Top Layer PCB Design On Eagle Software]]
|[[File:Bottom_Layout.png|500x600px|thumb|right|Bottom Layer PCB Design on Eagle Software]]
|}

{|
[[File:Top_View.png|500x600px|thumb|left|PCB Top Layer]]
|[[File:Bottom_View.png|500x600px|thumb|right|PCB Bottom Layer]]
|}

'''Infinity Mirror's Internal Circuit'''

[[File:Setup.jpeg|thumb|350x350px|center|Infinity Mirror: Internal Circuit of Embedded Entertainment Box]]

=='''Product Enclosure''' ==

To facilitate easy and convenient gaming experience and also act as an effective audio controller, a single 3D printed enclosure was designed which is spacious enough to accommodate the MCU modules like bluetooth, audio frequency analyzer and MP3 decoder on the PCB.

{|
|[[File:Top.jpeg|470px|thumb|left|Top View]]
|[[File:3D.png|430px|thumb|right|3D View]]
|}

===Final 3D Package===
[[File:Final_Setup.jpeg|thumb|600x600px|center|Infinity Mirror: Final Setup]]

=='''RGB LED Matrix'''==
A 32 x 64 RGB LED Matrix will be powered up through a 5V/4A DC adapter and is interfaced with the board to play the game 'Fruit Fury' with desired background song in the game-mode and to display the frequency bands and other relevant messages such as "Next", "Previous" and "Pause" in the music-mode. Only the INPUT IDC connector will be used because we are not cascading multiple matrices. The matrix has 2 planes (upper and lower), both of which will be programmed separately. In order to set RGB color data for each pixel in plane 1 (top half of the display) we use R1, G1 and B1 pins and for plane 2 we use R2, G2 and B2. By setting and resetting the CLOCK pulse, color data is set for every pixel in the row. Then the LATCH is set to mark end of the row and reset to move to next row. All of these steps are repeated at very less time intervals so that the human eye perceives it as one complete frame (Persistence of Vision).

Below is the description of the pins:

*R1 -> Sets upper panel's Red data
*G1 -> Sets upper panel's Green data
*B1 -> Sets upper panel's Blue data
*R2 -> Sets lower panel's Red data
*G2 -> Sets lower panel's Green data
*B2 -> Sets lower panel's Blue data
*A -> Sets row bit 0
*B -> Sets row bit 1
*C -> Sets row bit 2
*D -> Sets row bit 3
*CLK (Clock) -> Set to access each pixel
*LAT (Latch) -> Set to mark comletion of one row
*nOE (Output Enable) -> Set to switch the LEDs off when transitioning from one row to the next
*GND -> Ground pins to be connected with board's GND.

Below are the technical specifications:

*Pitch -> 4 mm
*Resolution -> 32 x 64 = 2048 dots
*Panel dimensions (l x b x h) in mm -> 256 x 128 x 13
*Working voltage/current rating -> 5v / 4A (max)
*Scan rate - 1/16
*Pixel component configuration (R,G,B) -> 1,1,1
*Weight -> 0.24 kg

=== Hardware Design ===
The hardware involves 5V/4A DC power supply adapter, barrel jack connectors and IDC cables to power up the LED matrix and communicate with the board. Below is the pin interfacing diagram.
[[File:Slide2.png|700x900px|thumb|center|LED Matrix Pin Diagram]]

=== Software Design ===
1. '''Fruit Fury - Game mode''' 

There are 2 tasks involved to ensure functioning of the game.

a) Task 1:
*Display the game's title screen. On pressing the onboard switch (SW1), game begins.
*Also used to display game over screen / win screen.
b) Task 2:
*Enter into game mode to play the game.
*Read accelerometer values (board orientation) and render game frame.
*Detect the player's board movement, compare it with fruit's location.
*Display score, lives and smash effects.
*Press another switch (SW0) to stop game and return to title screen or to restart the game once it is over.

 '''Game rules:''' 

a) Game comprises of 3 levels (level 2 on reaching score 15 and level 3 on reaching score 30) and 5 lives in total.

b) Primary objective is to tilt the board to the direction (North West, North East, South West or South East) in which the fruit appears in order to smash it.

c) Score increases by 1 point for smashing each fruit.

d) Bombs start appearing after completion of level 1, which costs a life when hit.

e) Level 3 is faster so make sure you tune your reflexes up.

f) Reach score 50 to win the game.

 '''Bonus:''' 

a) Streaks are rewarding. Smash 10 fruits straight up to win an extra life.

b) Look out for star fruits. Hit them to gain +2 points.

Choose your song to take all the inspiration you can and start smashing!

 '''2. Music mode''' 

a) Press the button to enjoy music-only mode. Graceful audio spectrum bands are displayed that dance to the tune of the chosen song.

b) A display is prompted to the user whenever music is paused or changed to next or previous song.

=== Implementation ===
'''LED Driver'''

1. Initialize the LED matrix by configuring necessary pin directions.

2. Disable Output Enable (OE) GPIO before feeding matrix data.

3. Select the required row by setting bits on A, B, C, D GPIO pins.

4. Loop through the pixels (columns) in the selected row and set the pixel color on R, G, B GPIO pins.

5. Set zero on R, G, B GPIO pins to mask that particular pixel.

6. Set and Reset the clock for pushing the R, G, B bits for each column.

7. Issue latch to mark the row's completion and reset latch before going to next row.

8. Follow the steps 2 to 7 for other rows.

<source lang="cpp">
for (uint8_t row = 0; row < (MAX_ROW / 2); row++) {
disableOE();
set_row(row);
for (uint8_t col = 0; col < MAX_COL; col++) {
LPC_GPIO0->PIN |= (1 << CLK);
set_color_bottom(game_matrix[row + (MAX_ROW / 2)][col]);
set_color_top(game_matrix[row][col]);
LPC_GPIO0->PIN &= ~(1 << CLK);
}
LPC_GPIO0->PIN |= (1 << LAT);
LPC_GPIO0->PIN &= ~(1 << LAT);
enableOE();
vTaskDelay(1);
}
</source>

'''Fruit Fury - Game mode'''

1. Generate the fruit's initial coordinate using random function (used srand() with time value as seed to get random pattern sets).

2. Construct the LED matrix array by drawing the fruit and borders.

3. Push the entire matrix data to LED driver to display the constructed matrix frame.

4. Then read the player's orientation and match with fruit's direction.

5. Modify game parameters (score, lives and level) based on player's results.

6. Stop game if all lives are over and display game over screen by switching to game init task (Task 1).

<source lang="cpp">
/* Push button to exit game */
if (LPC_GPIO0->PIN & (1 << SW0))
is_start_game = false;

if (is_start_game == true) {
/* Generate fruit's initial coordinate position */
get_fruit_begin_coord(&row_pt, &col_pt, &quadrant);
/* Generate final frame by considering fruit object at that position */
construct_game_matrix(row_pt, col_pt);
/* Draw final frame matrix of the game */
draw_final_game_frame();
/* Get the board direction from the user and increment score count */
compute_game_params(row_pt, col_pt, quadrant);
} else
vTaskResume(display_game_init_screen_t);
</source>

'''Spectrum display - Music mode'''

1. Read the audio frequency values from the graphic equalizer task and store it as an array.

2. Based on value of each frequency band, assign a height of the band (in pixels) to be drawn on the LED matrix.

3. Set a unique color for each band.

3. Push the entire matrix data to LED driver to display the constructed matrix frame.

4. Repeat steps 1 to 3 at required intervals to display repeating bands.

<source lang="cpp">

for (row = MAX_ROW - 1; row >= 1; row--) {
for (col = 7; col <= 62; col++) {
if ((row >= (MAX_ROW - band_height[0])) && col >= 7 && col <= 13 &&
band_num <= 0) {
band_matrix[row][col] = RED;
}
if ((row >= (MAX_ROW - band_height[1])) && col >= 14 && col <= 20 &&
band_num <= 1) {
band_matrix[row][col] = GREEN;
}
if ((row >= (MAX_ROW - band_height[2])) && col >= 21 && col <= 27 &&
band_num <= 2) {
band_matrix[row][col] = YELLOW;
}
if ((row >= (MAX_ROW - band_height[3])) && col >= 28 && col <= 34 &&
band_num <= 3) {
band_matrix[row][col] = BLUE;
}
if ((row >= (MAX_ROW - band_height[4])) && col >= 35 && col <= 41 &&
band_num <= 4) {
band_matrix[row][col] = PURPLE;
}
if ((row >= (MAX_ROW - band_height[5])) && col >= 42 && col <= 48 &&
band_num <= 5) {
band_matrix[row][col] = CYAN;
}
if ((row >= (MAX_ROW - band_height[6])) && col >= 49 && col <= 55 &&
band_num <= 6) {
band_matrix[row][col] = WHITE;
}
}
}

</source>

=='''MP3 Decoder'''==

The Audio Decoder breakout board communicates with the SJ board over SPI and is interfaced with the SPI-0 pins of the SJ board as follows:

*Clock Pin (Pin 13) - SJ SPI-0 Clock Pin
*MISO Pin (Pin 12) - SJ SPI-0 MISO Pin
*MOSI Pin (Pin 11) - SJ SPI-0 MOSI Pin
*MP3 CS: Chip Select Pin for the audio decoder to be activated while sending control signals.
*MP3 DCS: Chip Select Pin for the audio decoder to be activated while sending audio data signals.
*MP3 RST: Reset pin for the audio decoder.
*MP3 DREQ: Data Request Pin. Audio decoder signals that it is ready to accept next 32 bytes of audio data.
*VCC pin - SJ 3.3V pin
*GND pin - SJ GND Pin

=== Hardware Design ===
[[File:Slide1.png|800x900px|thumb|center|MP3 Decoder Pin Diagram]]

=== Software Design ===

[[File:Mp3_fLow.png|600x500px|thumb|center|MP3 Decoder Software Design]]

=== Implementation ===

We are interfacing MP3 Decoder on the SPI0 for reading the Audio Mp3 file from the SDCard and send Mp3 data to the Decoder. The purpose of this task is to send mp3 data to the mp3 decoder. This is a high priority as it is acting as a consumer. The producer task in our project is the task that reads songs that fill the freeRTOS queue with 4KB of data. The consumer task i.e the task that sends a song to the mp3 decoder that waits on an empty queue for portMAX_DELAY. Once the queue has data, the task starts sending 32 bytes at a time to the MP3 decoder. Once 32 bytes are sent, the task waits for the DREQ pin to get high. DREQ pin high indicates that the MP3 decoder unit is ready to take 32 bytes of data. For sending data, the task acquires the MUTEX so that no other task can use the SPI bus at the same time. Once the 32 bytes are sent, the MUTEX is released. This is the working of the task.

// Task to send data to decoder(High priority)
static uint8_t bytes_to_be_sent_to_decoder[READ_BYTES_FROM_FILE];
static uint8_t current_count = 0;
uint32_t start = 0, end = 0;
while (1) {
if (0 == current_count) {
xQueueReceive(mp3_queue, &bytes_to_be_sent_to_decoder[0], portMAX_DELAY);
}
start = (current_count * TRANSMIT_BYTES_TO_DECODER);
end = ((current_count + 1) * TRANSMIT_BYTES_TO_DECODER);
while (!mp3__dreq_get_status()) {
mp3__decoder_refresh();
vTaskDelay(2);
}
if (xSemaphoreTake(mp3_mutex, portMAX_DELAY)) {
mp3__data_cs();
send_32_bytes_to_decoder_using_ssp(start, end,
&bytes_to_be_sent_to_decoder[0]);
mp3__data_ds();
xSemaphoreGive(mp3_mutex);
if (current_count == COUNT - 1) {
current_count = start = end = 0;
} else {
current_count += 1;
}}}

=='''Audio Frequency Analyzer'''==

In the audio analyser, strobe and reset pins are used to select the DC peak output. Reset high resets the multiplexer. Reset low enables the strobe pin. At the leading edge of the first strobe, the first frequency band 63Hz is on the output. On each additional leading edge strobe the next frequency band(160Hz, 400Hz, 1kHz, 2.5kHz, 6.25kHz, 16kHz) is detected.

This analyser takes input from Audio decoder for left and right side music. SJ2 controls the RS and ST pins of the "Audio Frequency Analyzer" and reads input data from S pin which is connected to ADC pin (P0.26) of SJ2 board.

*Audio Analyzer S pin -> SJ2 ADC4 pin
*Audio Analyzer RS pin -> SJ2 P0.11 pin
*Audio Analyzer ST pin -> SJ2 P2.0 pin
*Audio Analyzer + pin -> SJ2 VCC pin
*Audio Analyzer - pin -> SJ2 GND pin
<div style="clear: both"></div>

====Audio Frequency Analyser====
Audio frequency analyser is working is most important task in order to get correct value. Incorrect initialisation and in efficient delays may cause error. In this project Init and reading of data at each frequncy band is implemented based on timing diagram shown as bellow:

[[File:244 Spark TimingDiagram AudioAnalyser.jpeg|thumb|550x400px|centre|Timing Diagram of Audio Analyser]]

The software Implementation to Init frequency analyser is as follow: 
1. Select ADC pin 
2. Select GPIO pin direction for reset pin and STOBE pin 
3. Reset Audio frequency analyser 

=='''Sensors Interface'''==

We have worked on two sensors for accessing our entertainment box i.e. Gesture Sensor and Accelerometer. The SJ-Two board has both sensors on board sensor which is interfaced on the I2C bus. Accelerometers are electromechanical devices that sense either static or dynamic forces of acceleration. Static forces include gravity, while dynamic forces can include vibrations and movement. The measurements are on 3-axis and these values can be calibrated to find the desired values.

In our project, an accelerometer is for controlling Controls in the MP3 Mode like PLAY,PAUSE,PLAY Next Song and Back to Previous Song.However in Game Mode we are playing our fruit fury game using Orientation sensor for Smashing fruits coming in Directions South East, South West ,North East and North West and We were using Gesture on SJ-Two Board for gesture recognitions Left, Right, UP and Down to change the configuration in MP3 Mode but after implementation we have realised that giving gesture is more complicated then getting signals from orientation.

=== Hardware Design ===

[[File:Sensor.png|800x900px|thumb|center|APDS9960 & MMA8452Q on board Sensors]]

=== Software Design ===

[[File:Sensor_FLow.png|600x500px|thumb|center|MMA8452Q Software Design]]

=== Implementation ===
The MMA8452Q has an orientation detection algorithm with the ability to detect all six orientations but we are using only 4 orientations i.e. Portrait Up, Portrait Down,Landscape Left and Landscape Right .The transition from portrait to landscape is fixed with a 45° threshold angle and a ±14° hysteresis angle. This allows the for a smooth transition from portrait to landscape at approximately 30° and then from landscape to portrait at approximately 60°.

[[File:accel_orient.png|800x900px|thumb|center|Portrait Orientation]]

We have used the following register settings to configure the sensors and getting all 4 directions and Orientation.

[[File:APDS_Register.png|800x900px|thumb|center|Registers of APDS9960]]

 

After reading the registers we are just performing the actions as per the Orientation detected.

[[File:Accel_register.png|800x900px|thumb|center|Registers of MMA8452Q]]

 

void perform_action_on_orientation(void *p)
{
orientation_e value;
while (1)
{
value = GetOrientation();
switch (value)
{
case Portrait_UP: // Prev Song
printf("Direction Left\n");
xSemaphoreGive(sem__prev_song);
break;
case Portrait_DOWN: // Next Song
printf("Direction Right\n");
xSemaphoreGive(sem__next_song);
break;
case Landscape_LEFT: // Resume/Play/
printf("Direction Up\n");
vTaskSuspend(handle__play_song);
vTaskSuspend(handle__freq_bands);
song_status = PLAY;
break;
case Landscape_RIGHT: // Pause/Stop/Volume Decrease
printf("Direction Down\n");
vTaskResume(handle__play_song);
vTaskResume(handle__freq_bands);
song_status = PAUSE;
break;
default:
break;
}
vTaskDelay(50);
}}

=='''Bluetooth Interface'''==
The SJ-two is connected to the Bluetooth module through the Serial interface (UART3) and we have configured it at 38400 baud rate with 8-bit data and 1 stop bit using the Communication Mode. It is used to send and receive the Game and Music data from our entertainment device to an android application.

=== Hardware Design ===

[[File:Slide3.png|700x900px|thumb|center|Bluetooth Interface Pin Diagram]]

===HC-05 Bluetooth module===
HC-05 Bluetooth Module is used to set up wireless communication between the entertainment device and the Android phone. The right section of the Bluetooth Board has connection pins for power and signals as well as a 5V to 3.3V Regulator, LED, and level shifting.

'''HC-05 PinOut'''
* EN: N/A
* VCC: 5V Power
* GND: Ground
* TXD: Serial Transmit pin connected to RXD3 of SJ board
* RXD: Serial Receive pin connected to TXD3 of SJ board
* STATE: States if connected or not

=== Software Design ===

[[File:Bluetooth_Sw_diagram.png|600x500px|thumb|center|Bluetooth Software Design]]

=== Implementation ===

An accelerometer is used in the MP3 Mode to implement functionalities such as play, pause, switch to next and previous songs and volume control. In the game mode the “Fruit fury” game is played by smashing fruits appearing in the directions South East, South West, North East and North West. UART3 is used as communication protocol.The Bluetooth commands that we are using to interact with Mobile app and Device are as follows:

GAMING = 0xA1,
NORTH_EAST = 0x71,
NORTH_WEST = 0x72,
SOUTH_WEST = 0x73,
SOUTH_EAST = 0x74,
MUSIC = 0xA2,
SONG_LIST = 0xA3,
NEXT_SONG = 0xC2,
TOGGLE_SONG = 0xC1,
PREV_SONG = 0xC0,
ACK = 0x00,
NACK = 0xFF,
VOL_INC = 0xB1,
VOL_DEC = 0xB0

=='''Mobile Application'''==

{|
|[[File:Modes.jpeg|230px|thumb|List Of Feature in the APP]]
|[[File:GAME.jpeg|230px|thumb|Game Mode]]
|[[File:Mp3_song.jpeg|230px|thumb|MP3 Mode]]
|[[File:SongList.jpeg|230px|thumb|List Of Songs in SD Card]]
|}

=== Software Design ===

The Android app has been built using the cross platform framework [https://flutter.dev/ Flutter]

The app is composed of 3 parts, '''Game Mode''', '''MP3 Mode''' and '''MP3 Song List'''. On the main screen we first connect to the bluetooth before establishing connection with any of the modes. The working of each mode is explained in each subsection below.

A few variables to note in advance
ACK = 0x00, sent when successful
NACK = 0xFF, sent incase there is any error

====1. Game Mode ====

Wireless communication with the Entertainment box communication over Bluetooth protocol. Android Application is created which provides an interface to exchange data and configure the device.To enter the Game Mode screen we first check if the Bluetooth Connection is established. We send in a one byte data 0xa1 over bluetooth to the SJ2 Board and get back the response "a1$ack/nack$##" We then enter the game mode which displays a joystick that can be oriented to a direction wherever the fruit appears on the LED matrix. The corresponding orientation value is then transmitted.If the fruit had appeared in any of the quadrant then will send data from BLE APP to SJTwo Board.

'''1.''' First Quadrant (North-East): 0x71 
'''2.''' Second Quadrant (North-West): 0x72 
'''3.''' Third Quadrant (South-West): 0x73 
'''4.''' Fourth Quadrant (South-East): 0x74 

====2. MP3 Mode ====

To enter the MP3 Mode screen we first check if the Bluetooth Connection is established similar to the Game Mode. We send in one byte of data 0xa2 over bluetooth to the SJ2 Board and get back the response "a2$ack/nack$volumeInfo$currentSong$isPlaying/isPaused$##" where isPlaying is 1 and isPaused is 0. These values are loaded into the MP3 Mode Screen as initial values for the current song playing. We can then see a screen where we can control the various aspects of playing songs i.e Playing and Pausing the song, Go to next song and and Go to the previous song. We can also control the volume remotely.Controlling each part of this interface is the same as sending a single byte of data over bluetooth to the SJ2 Board.

'''1.''' Playing and Pausing Song - We just toggle the state of the Song. We issue this command by sending 0xc1 which is the Toggle State command. 
'''2.''' Next Song and Previous Song - Command for the previous and next song is 0xC0 and 0xC2. 
'''3.''' Control Volume remotely - For volume we divide the percentage 100 percent in 16 parts. We can send the value between 0xb0 to 0xbf in increments of one step. This is parsed on the SJ2 Board and converted to an equivalent volume signal. 

====3. MP3 Song List ====
To get the list of MP3 Songs which are present in the SD card, we first check if the Bluetooth Connection is established similar to the Game Mode and MP3 Song mode. We send in one byte of data 0xa3 over bluetooth to the SJ2 Board and get back the response "a3$ack/nack$data$data$...$##". APIs that were designed to read song information and data by Audio Decoder, will be used for achieving this functionality.

=='''OLED Screen'''==

[[File:Oled_screen.jpeg|thumb|600x600px|center|Oled Screen Functionality]]

=== Software Design ===

The open source package [https://github.com/olikraus/u8g2 u8g2] has been used.
There are already ready made functions for various OLED Drivers. The indepth setup guide can be found [https://github.com/olikraus/u8g2/wiki/u8g2setupc here]

=== Implementation ===

The u8g2 library is a very robust library which means that this code can be extended for any microcontroller as long as the interface is written properly.

We needed to write 2 main functions, outlined below, i.e byte_cb and gpio_and_delay_cb using the function prototype `uint8_t u8x8_lpc_gpio_and_delay(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr)`.

Since the SJ2 Board is connected to the OLED Screen on the SPI1 Bus we also need to write the SPI1 driver, mainly a method to that sends data over SPI to the Slave device i.e the OLED Screen

=== Initializing the u8g2 for LPC4078 ===

<source lang="cpp">

// Created a file `u8g2_wrapper.h

static gpio_s dc;
static u8g2_t u8g2;

void u8g2_wrapper__init(gpio_s *dc_pin) {
u8g2_Setup_ssd1306_128x64_vcomh0_1(&u8g2, U8G2_R0, u8x8_byte_4wire_hw_spi, u8x8_lpc_gpio_and_delay);
u8g2_InitDisplay(&u8g2);
u8g2_SetPowerSave(&u8g2, 0);

dc.pin_number = dc_pin->pin_number;
dc.port_number = dc_pin->port_number;
}

u8g2_t *u8g2_wrapper__get_instance() { return &u8g2; }

uint8_t u8x8_lpc_gpio_and_delay(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr) {
switch (msg) {
case U8X8_MSG_GPIO_AND_DELAY_INIT:
delay__ms(1);
break;
case U8X8_MSG_DELAY_MILLI:
delay__ms(arg_int);
break;
case U8X8_MSG_GPIO_DC:
// DONE, Write to the GPIO_DC Pin
if (arg_int == 0) {
gpio__reset(dc);
} else {
gpio__set(dc);
}
break;
case U8X8_MSG_GPIO_RESET:
break;
}
return 1;
}

uint8_t u8x8_byte_4wire_hw_spi(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr) {
uint8_t *data;
switch (msg) {
case U8X8_MSG_BYTE_SEND:
data = (uint8_t *)arg_ptr;
while (arg_int > 0) {
ussp1__exchange_byte((uint8_t)*data);
data++;
arg_int--;
}
break;
case U8X8_MSG_BYTE_INIT:
break;
case U8X8_MSG_BYTE_SET_DC:
if (arg_int == 0) {
gpio__reset(dc);
} else {
gpio__set(dc);
}
break;
case U8X8_MSG_BYTE_START_TRANSFER:
break;
case U8X8_MSG_BYTE_END_TRANSFER:
break;
default:
return 0;
}
return 1;
}

</source>

=='''Technical Challenges'''==

1. '''RGB LED Matrix''' 

* Getting control of the matrix was challenging as it needs to follow specific sequence of pin enabling/disabling at appropriate timing.

* Setting right delays to avoid flickers and get smooth transitioning between frames by using delays or for loops.

* Fixing high CPU utilization by changing delay__us to vTaskDelay.

* Designing elements of the game (title screen and fruit objects) which required careful plotting of pixel data.

2. '''Audio Decoder''' 

a) The CPU utilization for sending a song task was very high (80% +).
* In order to reduce the utilization, we gave the vTaskDelay(1) while waiting for the DREQ to be high. The high DREQ indicates that the decoder is ready to receive next 32 bytes of data. So meanwhile, when the DREQ pin is low, we made task to sleep for vTaskDelay(1). After doing this, we significantly reduced the CPU utilization to 15%. We tried with vTaskDelay(2) to get CPU utilization of 10%.
* We further tried to make the CPU utilization below 10%. This was really a tough challenge, and figured out that the actual SPI clock is 1Mhz which is too slow as SPI is meant to operate at much higher speed. We changed the clock rate of SPI to 12MHz but the song speed was too slow. We checked the datasheet of the Mp3 decoder and set the internal clock multiplier to 4.5x. This make the shield operate at high clock rates at 12.XX Mhz. So keeping this in mind we made the SPI speed to 12MHz which is safe. We successfully achieved CPU utilization of 5-6% which is very much in the acceptable range.

3. '''PCB Designing''' 

* We realized that using GPP for long term is not a good idea. Initially we spent time in debugging our hardware and later we have realized like we can’t take this for our final day.
* We did multiple reviews before ordering our final PCB as none of us did that earlier. We have faced issue in manual routing on Eagle Autodesk but our ISA Prashant helped us and he reviewed our PCB design twice.

4. '''Mobile Application''' 

* The main challenge of the Mobile application was to make the UI interactive while getting data asynchronously over the Bluetooth module.
* There was a global listener stream implemented that got the value and concatenate the string till we received the end frame (##).
* However the challenge still existed to know which screen has called what data which prompted us to create the key and ACK/NACK pair in the start.
* The Mobile app is completely data reactive, which means that the UI components render and change according to the data provided. This caused a lot of issues mainly since we tried polling methods to make sure that the UI remains up to date with the STATE of the SJ2 Board.
* A manual approach was opted for mainly to make the system more deterministic and for better debugging capabilities.

=='''Suggestions for Future Students'''==
 '''RGB LED Matrix''' 

* To begin with, focus on writing a simple driver to get control of 1 pixel at a targeted location and then use appropriate loops to light up the entire row/column.

* Make sure all pixels are able to light up with all possible colors to eliminate hardware defects.

* Try with minimum / no delays, print tick counts and then come up with meaningful delay numbers.

* Optimize the code (minimum delays, avoiding repetitive function calls, etc.) to bring down the CPU usage level.

* Use the link in the references to draw desired elements and generate the matrix.

 '''Tips for getting GOOD Grades and to remain in top 3 teams''' 
* Select your teammates wisely, and make sure every one dedicates themself for this project.
* Be an active member of your team and review rubrics for the final DEMO.
* As soon as the professor mentions the project, please start working on the project otherwise, in the end, you have to struggle with finals and you will be left with less time for testing and you have to struggle in demo.

 '''General tips''' 
* Remember the KISS approach when you code. (Keep It Simple and Stupid).
* For this project, one should know the basics in C/ C++, FreeRTOS, and some good debugging skills. Because if you don't have one, you will eventually end up spending more time debugging your problem.
* Always give meaningful names to the variable or the function, so a third person reviewing the code gets an overall idea by just reading the name.

=='''Conclusion'''==
It was a really great working experience for all of us. We were really thrilled from the beginning that we will be working on something that is quite relevant in the industries. We worked as a team of four which helped us all to know the importance of team-work and co-ordination. We learned many great stuff like

* State Design using FreeRTOS
* FreeRTOS APIS when task handles are NULL vs when Initialised.
* Uses of extern and global variables as opposed to encapsulation i.e static inside private 'c' files.
* Learning Optimization through the integration of our peer's individual modules
* Improving CPU utilisation of the main LED and MP3 tasks.
* Workload sharing and cooperation amongst peers.
* Sharing ideas and debugging a common problem together i.e team building.
* We realised that using GPP for long term is not a good idea, there were some breakdown in the wires and our MP3 stopped working. Initially we spent a lot of time debugging hardware and doing soldering. So we started designing the PCB, and when our PCB was done, we spent hardly any time debugging the hardware.
* Git : We learnt all the basic of GIT and it plays an important to role for source code versioning.

There were a lot of problems while doing this project but it was a steep learning curve. In the end we were able to achieve our objective with really good results.

=='''Project Video'''==
https://youtu.be/vVjHCoyWYz4

=='''Project Source Code'''==
* Git Project Link (Individual Modules): [https://gitlab.com/Infinity_Mirror/infinity_mirror-cmpe-244]
* Git Project Link: [https://gitlab.com/ganeshram2493/infi_mirror]

=='''Project Presentation File'''==
* [https://drive.google.com/file/d/1Q_Xvs-a2feQcr-FbPEKbwmlhi35hqNxX/view?usp=sharing Presentation Link]

=='''References'''==
=== Acknowledgement ===

We would like to express our gratitude to Professor Preetpal Kang for generously sharing his time and knowledge with us and guiding us through the completion of this project. We would also like to thank the Prashant Gandhi(ISA) for their valuable advice and constructive feedback.

=== References Used ===

====== Flutter Android GUI ======
* [https://material.io/resources/icons/?style=baseline Material Design Icons]
* [https://flutter.dev/ Building a Dynamic UI with Flutter]
* [https://www.youtube.com/channel/UCwXdFgeE9KYzlDdR7TG9cMw Flutter Youtube Channel]

====== RGB LED Matrix Interfacing and Designing ======
* [https://www.sparkfun.com/products/14718 Datasheet and Hookup guide]
* [https://cdn-learn.adafruit.com/downloads/pdf/32x16-32x32-rgb-led-matrix.pdf?timestamp=1543806512/ Wiring and pin information]
* [https://www.riyas.org/2013/12/online-led-matrix-font-generator-with.html Hex code generator to build LED matrix models]

====== MP3 Decoder and Frequency Analyzer ======
* [https://www.sparkfun.com/datasheets/Components/General/MSGEQ7.pdf Seven Band Graphic Equalizer MSGEQ7 Data Sheet]
* [https://www.kr4.us/SparkFun-MP3-Player-Shield.html?gclid=EAIaIQobChMIov3f7PWc2wIVDtVkCh0-rgStEAYYASABEgIEgPD_BwE SparkFun-MP3-Player-Shield Datasheet]

====== Gesture & Orientation Sensors ======
* [https://cdn.sparkfun.com/assets/learn_tutorials/3/2/1/Avago-APDS-9960-datasheet.pdf Gesture Sensor Data Sheet]
* [https://learn.sparkfun.com/tutorials/mma8452q-accelerometer-breakout-hookup-guide/all Accelerometer Sensor Data]

====== General/Miscellaneous ======
* [http://socialledge.com/sjsu/index.php/FreeRTOS_Tutorial FreeRTOS Tutorial]
* [https://sjsu-dev2.readthedocs.io/en/latest/?badge=latest SJTwo-c Documentation]

File:Title Screen.jpeg

2019-12-18T23:34:17Z

Proj user22: Proj user22 uploaded a new version of File:Title Screen.jpeg

Game Fury Title Screen

File:Oled screen.jpeg

2019-12-18T23:31:51Z

Proj user22:

File:Title Screen.jpeg

2019-12-18T23:17:01Z

Proj user22: Game Fury Title Screen

Game Fury Title Screen

F19: Infinity Mirror

2019-12-18T23:01:22Z

Proj user22: /* Technical Challenges */

== '''Abstract''' ==

The main theme of the project is to build an interactive embedded system consisting of two entertainment modes - Music and Gaming. On the music mode, the MP3 decoder module reads songs from an SD card on the MCU board and plays the music through a speaker. It deals with the convergence of various services such as playing a game with background music, control volume, switch and pause/play songs. While the song is being played, audio frequency spectrum bands based on music tune are displayed on the LED Matrix band visualization etc. On the game mode, a fruit smashing game called “Fruit Fury” is implemented where the user needs to orient the MCU board in a direction according to where the fruit appears on the LED matrix. Alongside, the user can listen and switch songs. To achieve the above functionalities, various elements such as Audio Decoder, Audio frequency analyzer, 32x64 RGB LED Matrix and HC-05 bluetooth module and Android application are integrated.

[[File:High_level1.png|800px|thumb|center|Block Diagram of Infinity Mirror]]

== '''Introduction & Objectives''' ==

The key features supported by the system is real-time orientation recognition & trigger respective actions in 2 modes - MP3 mode and Game mode.

MP3 MODE:

1. Determine the accelerometer sensor values based on the orientation of the board and perform music control such as play, pause, volume control and changing songs.

2. In response, retrieve the data from the SD Card & communicate to the audio decoder for appropriate audio streaming.

3. Also implemented interaction with HC-05 bluetooth module through a customized mobile application and provide same operations.

4. Display frequency spectrum bands in sync to the tune of the song played.

GAME MODE - Fruit Fury:

1. Determine the accelerometer sensor values based on the orientation of the board and hit the fruit in corresponding direction.

2. Incorporating provision on the board's switches to change to next or previous song.

3. Also implemented interaction with HC-05 bluetooth module through a customized mobile application and play the game through the same.

'''Project Objectives'''
'''1. Audio Decoder''' - Fetches song data from the SD card and plays it over a speaker.
'''2. RGB LED Matrix''' - Display frequency bands on music mode or view the game on game mode.
'''3. Audio Frequency Analyzer''' - To convert the audio data into 7 spectrum bands which is then displayed as individual colored bands on the LED matrix.
'''4. Bluetooth HC-05''' - Interfaces the system using Bluetooth to an Android application.

'''Team Objectives'''
'''1.''' Learn each and every module as much as possible, in order to develop an overall product.
'''2.''' Understand the proper use of queues and semaphores in order to send/receive the data between multiple tasks.
'''3.''' Learn to integrate all modules and ensuring smooth transition, communication and context switching at desired time intervals.
'''4.''' Document and track all the bugs encountered during development and learn to update git repository after every fix.

== '''Team Members & Technical Responsibilities''' ==
[[File:cmpe244_F19_Infinity_Mirror_members.jpeg|thumb|500x500px|TEAM INFINITY MIRROR|right]]

*'''''[http://linkedin.com/in/aakash-chitroda-17841740 Aakash Chitroda]'''''
** MP3 Audio Encoder/Decoder
** Audio frequency Analyzer logic

*'''''[https://www.linkedin.com/in/ganeshram93 Ganesh Ram]'''''
** Interfacing of LED Matrix and driver design
** Game logic design
** Audio frequency spectrum logic on LED
** Packaging

*'''''[https://www.linkedin.com/in/niket-naidu-30090a134/ Niket Naidu]'''''
** Android & Bluetooth Application
** OLED Interfacing and Designing
** PCB Design improvements
** Accelerometer Sensor integration with OLED Screen

*'''''[https://www.linkedin.com/in/vidushi-jain-048b992a Vidushi Jain]'''''
** Bluetooth Communication
** Interfacing of Gesture & Accelerometer Sensors
** Hardware Designing & PCB Integration

 

== '''Administrative Responsibilities''' ==
{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|- style="vertical-align: top;"
! colspan="5" style="background:#588ecc" | Administrative Roles 
|-
! style="text-align: left;" |
* Team Lead 
| Aakash Chitroda 
|-
! style="text-align: left;" |
* Finance Manager
| Niket Naidu 
|-
! style="text-align: left;" |
* Git Repository Manager 
| Vidushi Jain 
|-
! style="text-align: left;" |
* Wiki Report Manager 
| Vidushi Jain 
 Ganesh Ram 
|-
! style="text-align: left;" |
* Bill of Materials Manager 
| Ganesh Ram 
|}

== '''Team Deliverables Schedule''' ==

{| class="wikitable"
|-
! scope="col" style="text-align: left;" style="background:#588ecc;" | WEEK
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
START DATE 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
END DATE 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
TASK DETAILS 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
STATUS 
|-
| 1 || 15 Oct 2019 || 22 Oct 2019 ||
*Create and establish GitLab repository
*Establish slack channel and invite Preet
*Look through previous years projects and study it
*Distribute major roles among team members
|| Completed Completed Completed Completed 
|-
| 2 || 23 Oct 2019 || 29 Oct 2019 ||
* Create a Bill of Materials 
* Select and order Parts 
* Review Data-sheet and Interfacing Of LED Matrix(Ganesh) 
* Review Data-sheet for Gesture sensor(Vidushi) 
* Make Repo on Gitlab for all modules - Follow Naming Convention. 
|| Completed Completed Completed Completed Completed 
|-
| 3 || 30 Oct 2019 || 5 Nov 2019 ||
* Review Data-sheet of Audio MP3 shield(Aakash) 
* Start Soldering for LED matrix and MP3 Shield 
* Start Soldering of Headers for MP3 Shield & decoder
* Environmental setup of Android & Web applications(Niket) 
* Implementation of Gesture Detection (Vidushi)
* Implementation of displaying text and basic shapes on LED Matrix (Ganesh)
|| Completed Completed Completed Completed Completed Completed 
|-
| 4 || 6 Nov 2019 || 12 Nov 2019 ||
* Implementation of OLED Driver(Niket)
* Initialization the Audio Decoder through SPI communication and read manufacturer ID 
* Implementation of random frequency bands on LED matrix (Ganesh)
* Implementation of communication Between two task(gesture_detect & LED_Display) using queues and semaphores (Vidushi)
* Display Gesture Sensor Directions on OLED in a Text (Vidushi & Niket)
* Read Song from SD Card 
|| Completed Completed Completed Completed Completed Completed 
|-
| 5 || 13 Nov 2019 || 19 Nov 2019 ||
* Circuit Simulation in Diptrace/Eagle Tool. 
* PCB Layout Design in Diptrace/Eagle Tool. 
* Finalize Components placement on PCB. 
* Read Song from SD Card and send to MP3 Shield 
* Receive Values from audio spectrum and send to display task to display on LED Matrix.(Aakash & Ganesh) 
* Interface OLED with onboard buttons to access the list of songs (Niket)
* Developing logic for the ball movement and translating hand-gesture control into LED movement.(Ganesh)
|| Completed Completed Completed Completed Completed Completed Completed 
|-
| 6 || 20 Nov 2019 || 26 Nov 2019 ||
* Interfacing of all modules sensors, bluetooth , MP3 and LED Matrix
* Test whole implementation after integration of all modules
* Test for stack overflow and system crash
* Debug and Test the Play/Pause/Stop functionality of MP3 player 
* Integrate fruit Fury game logic
* Update Final Wiki Schedule. 
|| Completed Completed Completed Completed Completed Completed Completed 
|-
| 8 || 27 Nov 2019 || 3 Dec 2019 ||
* Additional Feature week
* Establish Bluetooth communication of Device and Mobile APP 
* Develop UI on Android application. 
* Add Play/Pause/Stop and Song selection functionality to the APP. 
* Update Wiki with new details and information. 
* Enhanced game logic and integrated song play feature in game 
|| Completed Completed Completed Completed Completed 
|-
| 9 || 4 Dec 2019 || 10 Dec 2019 ||
* TESTING - CRITICAL WEEK 
* Packaging of hardware board and related components. 
* Check overall robustness of the complete system. 
* Establish complete connection on PCB 
* Update wiki with details. 
|| Completed Completed Completed Completed Completed 
|-
| 10 || 11 Dec 2019 || 17 Dec 2019 ||
* All hands on testing and final bug fixes. 
* Check for tuning or calibration of sensors if required. 
* Complete end-to-end testing for various scenarios and conditions. 
* Create the semester long project activity video and upload to YouTube. 
* Update and finalize wiki. 
|| Completed Completed Completed Completed Completed 
|-
| 11 || 18 Dec 2019 || ||
* '''DEMO: Final Project''' 
* '''SUBMISSION: Final Project Wiki''' 
|| Completed Completed 
|}

== '''Bill of Materials (General Parts)''' ==

{| class="wikitable"
|-
! scope="col" style="text-align: left;" style="background:#588ecc;" | PART NAME 

! scope="col" style="text-align: left;" style="background:#588ecc;" | 
PART MODEL & SOURCE 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
QUANTITY 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
COST PER UNIT (USD) 
|-
|
* Micro-Controller Eval-Boards
|
* LPC 4078 (Purchased from Preet Kang)
|
* 1
|
* 50.00

|-
|
* Audio decoder Breakout Board
|
* [https://www.sparkfun.com/products/12660 SparkFun MP3 Player Shield]
|
* 1
|
* 26.95

|-
|
* Audio Analyzer
|
* [https://www.amazon.com/dp/B074T9H8JV/ DFR0126 Audio Analyzer]
|
* 1
|
* 19.00

|-
|
* RGB LED matrix
|
* [https://www.sparkfun.com/products/14718 32 x 64 RGB LED Matrix Panel]
|
* 1
|
* 49.95

|-
|
* Power supply
|
* [https://www.sparkfun.com/products/15352 5V / 4A Power Supply]
|
* 1
|
* 12.95

|-
|
* Audio Speakers
|
* 3.5mm Jack Stereo Speakers
|
* 1
|
* Own

|-
|
* PCB parts and other Miscellaneous parts
|
* Anchor Electronics and Digikey '''
|
* 1
|
* 50.00

|-
|
* 2 way mirror
|
* [https://www.amazon.com/gp/product/B06Y2C79FC/ref=ppx_yo_dt_b_asin_title_o03_s00?ie=UTF8&psc=1 2-way mirror ]
|
* 1
|
* 7.64

|-
|
* PCB Fabrication
|
* [https://jlcpcb.com/quote JLCPCB]
|
* 5
|
* 29.53
|}

 

== '''Printed Circuit Board''' ==

=== Design And Architecture ===

We have designed the custom PCB using Eagle Software and as well as one prototype board in which we have connected all the modules with SJ-Two board. PCB was sent to fabrication to JLCPCB China which provided PCB with lead time of 1 week. We have implemented 2 layers of PCB with all of the parts in top layer.

'''Components Placements on PCB and on Prototype Board'''
'''1.''' One SJ-Two board is fitted onto the top of the 3D printed lid cover which with a slot opening for 2x40 IDC cable.
'''2.''' MP3 Decoder is connected with SJ-Two board and will be place on the right side of PCB and as well as on Prototype board.
'''3.''' Bluetooth Module needs only 4 pins to connect with SJ-Two and goes to UART3 and placed on the top left of the board.
'''4.''' LED Matrix is connected using 2x8 IDC cable pins on the top left side of the board.
'''5.''' Audio Frequency Analyzer is placed on the bottom side of PCB.
'''6.''' Power supply of 5v and 3.3v provisions are made on the bottom left side of PCB.

{|
[[File:Top_Layout.png|500x600px|thumb|left|Top Layer PCB Design On Eagle Software]]
|[[File:Bottom_Layout.png|500x600px|thumb|right|Bottom Layer PCB Design on Eagle Software]]
|}

{|
[[File:Top_View.png|500x600px|thumb|left|PCB Top Layer]]
|[[File:Bottom_View.png|500x600px|thumb|right|PCB Bottom Layer]]
|}

'''Infinity Mirror's Internal Circuit'''

[[File:Setup.jpeg|thumb|350x350px|center|Infinity Mirror: Internal Circuit of Embedded Entertainment Box]]

=='''Product Enclosure''' ==

To facilitate easy and convenient gaming experience and also act as an effective audio controller, a single 3D printed enclosure was designed which is spacious enough to accommodate the MCU modules like bluetooth, audio frequency analyzer and MP3 decoder on the PCB.

{|
|[[File:Top.jpeg|470px|thumb|left|Top View]]
|[[File:3D.png|430px|thumb|right|3D View]]
|}

===Final 3D Package===
[[File:Final_Setup.jpeg|thumb|600x600px|center|Infinity Mirror: Final Setup]]

=='''RGB LED Matrix'''==
A 32 x 64 RGB LED Matrix will be powered up through a 5V/4A DC adapter and is interfaced with the board to play the game 'Fruit Fury' with desired background song in the game-mode and to display the frequency bands and other relevant messages such as "Next", "Previous" and "Pause" in the music-mode. Only the INPUT IDC connector will be used because we are not cascading multiple matrices. The matrix has 2 planes (upper and lower), both of which will be programmed separately. In order to set RGB color data for each pixel in plane 1 (top half of the display) we use R1, G1 and B1 pins and for plane 2 we use R2, G2 and B2. By setting and resetting the CLOCK pulse, color data is set for every pixel in the row. Then the LATCH is set to mark end of the row and reset to move to next row. All of these steps are repeated at very less time intervals so that the human eye perceives it as one complete frame (Persistence of Vision).

Below is the description of the pins:

*R1 -> Sets upper panel's Red data
*G1 -> Sets upper panel's Green data
*B1 -> Sets upper panel's Blue data
*R2 -> Sets lower panel's Red data
*G2 -> Sets lower panel's Green data
*B2 -> Sets lower panel's Blue data
*A -> Sets row bit 0
*B -> Sets row bit 1
*C -> Sets row bit 2
*D -> Sets row bit 3
*CLK (Clock) -> Set to access each pixel
*LAT (Latch) -> Set to mark comletion of one row
*nOE (Output Enable) -> Set to switch the LEDs off when transitioning from one row to the next
*GND -> Ground pins to be connected with board's GND.

Below are the technical specifications:

*Pitch -> 4 mm
*Resolution -> 32 x 64 = 2048 dots
*Panel dimensions (l x b x h) in mm -> 256 x 128 x 13
*Working voltage/current rating -> 5v / 4A (max)
*Scan rate - 1/16
*Pixel component configuration (R,G,B) -> 1,1,1
*Weight -> 0.24 kg

=== Hardware Design ===
The hardware involves 5V/4A DC power supply adapter, barrel jack connectors and IDC cables to power up the LED matrix and communicate with the board. Below is the pin interfacing diagram.
[[File:Slide2.png|700x900px|thumb|center|LED Matrix Pin Diagram]]

=== Software Design ===
1. '''Fruit Fury - Game mode''' 

There are 2 tasks involved to ensure functioning of the game.

a) Task 1:
*Display the game's title screen. On pressing the onboard switch (SW1), game begins.
*Also used to display game over screen / win screen.
b) Task 2:
*Enter into game mode to play the game.
*Read accelerometer values (board orientation) and render game frame.
*Detect the player's board movement, compare it with fruit's location.
*Display score, lives and smash effects.
*Press another switch (SW0) to stop game and return to title screen or to restart the game once it is over.

 '''Game rules:''' 

a) Game comprises of 3 levels (level 2 on reaching score 15 and level 3 on reaching score 30) and 5 lives in total.

b) Primary objective is to tilt the board to the direction (North West, North East, South West or South East) in which the fruit appears in order to smash it.

c) Score increases by 1 point for smashing each fruit.

d) Bombs start appearing after completion of level 1, which costs a life when hit.

e) Level 3 is faster so make sure you tune your reflexes up.

f) Reach score 50 to win the game.

 '''Bonus:''' 

a) Streaks are rewarding. Smash 10 fruits straight up to win an extra life.

b) Look out for star fruits. Hit them to gain +2 points.

Choose your song to take all the inspiration you can and start smashing!

 '''2. Music mode''' 

a) Press the button to enjoy music-only mode. Graceful audio spectrum bands are displayed that dance to the tune of the chosen song.

b) A display is prompted to the user whenever music is paused or changed to next or previous song.

=== Implementation ===
'''LED Driver'''

1. Initialize the LED matrix by configuring necessary pin directions.

2. Disable Output Enable (OE) GPIO before feeding matrix data.

3. Select the required row by setting bits on A, B, C, D GPIO pins.

4. Loop through the pixels (columns) in the selected row and set the pixel color on R, G, B GPIO pins.

5. Set zero on R, G, B GPIO pins to mask that particular pixel.

6. Set and Reset the clock for pushing the R, G, B bits for each column.

7. Issue latch to mark the row's completion and reset latch before going to next row.

8. Follow the steps 2 to 7 for other rows.

<source lang="cpp">
for (uint8_t row = 0; row < (MAX_ROW / 2); row++) {
disableOE();
set_row(row);
for (uint8_t col = 0; col < MAX_COL; col++) {
LPC_GPIO0->PIN |= (1 << CLK);
set_color_bottom(game_matrix[row + (MAX_ROW / 2)][col]);
set_color_top(game_matrix[row][col]);
LPC_GPIO0->PIN &= ~(1 << CLK);
}
LPC_GPIO0->PIN |= (1 << LAT);
LPC_GPIO0->PIN &= ~(1 << LAT);
enableOE();
vTaskDelay(1);
}
</source>

'''Fruit Fury - Game mode'''

1. Generate the fruit's initial coordinate using random function (used srand() with time value as seed to get random pattern sets).

2. Construct the LED matrix array by drawing the fruit and borders.

3. Push the entire matrix data to LED driver to display the constructed matrix frame.

4. Then read the player's orientation and match with fruit's direction.

5. Modify game parameters (score, lives and level) based on player's results.

6. Stop game if all lives are over and display game over screen by switching to game init task (Task 1).

<source lang="cpp">
/* Push button to exit game */
if (LPC_GPIO0->PIN & (1 << SW0))
is_start_game = false;

if (is_start_game == true) {
/* Generate fruit's initial coordinate position */
get_fruit_begin_coord(&row_pt, &col_pt, &quadrant);
/* Generate final frame by considering fruit object at that position */
construct_game_matrix(row_pt, col_pt);
/* Draw final frame matrix of the game */
draw_final_game_frame();
/* Get the board direction from the user and increment score count */
compute_game_params(row_pt, col_pt, quadrant);
} else
vTaskResume(display_game_init_screen_t);
</source>

'''Spectrum display - Music mode'''

1. Read the audio frequency values from the graphic equalizer task and store it as an array.

2. Based on value of each frequency band, assign a height of the band (in pixels) to be drawn on the LED matrix.

3. Set a unique color for each band.

3. Push the entire matrix data to LED driver to display the constructed matrix frame.

4. Repeat steps 1 to 3 at required intervals to display repeating bands.

<source lang="cpp">

for (row = MAX_ROW - 1; row >= 1; row--) {
for (col = 7; col <= 62; col++) {
if ((row >= (MAX_ROW - band_height[0])) && col >= 7 && col <= 13 &&
band_num <= 0) {
band_matrix[row][col] = RED;
}
if ((row >= (MAX_ROW - band_height[1])) && col >= 14 && col <= 20 &&
band_num <= 1) {
band_matrix[row][col] = GREEN;
}
if ((row >= (MAX_ROW - band_height[2])) && col >= 21 && col <= 27 &&
band_num <= 2) {
band_matrix[row][col] = YELLOW;
}
if ((row >= (MAX_ROW - band_height[3])) && col >= 28 && col <= 34 &&
band_num <= 3) {
band_matrix[row][col] = BLUE;
}
if ((row >= (MAX_ROW - band_height[4])) && col >= 35 && col <= 41 &&
band_num <= 4) {
band_matrix[row][col] = PURPLE;
}
if ((row >= (MAX_ROW - band_height[5])) && col >= 42 && col <= 48 &&
band_num <= 5) {
band_matrix[row][col] = CYAN;
}
if ((row >= (MAX_ROW - band_height[6])) && col >= 49 && col <= 55 &&
band_num <= 6) {
band_matrix[row][col] = WHITE;
}
}
}

</source>

=='''MP3 Decoder'''==

The Audio Decoder breakout board communicates with the SJ board over SPI and is interfaced with the SPI-0 pins of the SJ board as follows:

*Clock Pin (Pin 13) - SJ SPI-0 Clock Pin
*MISO Pin (Pin 12) - SJ SPI-0 MISO Pin
*MOSI Pin (Pin 11) - SJ SPI-0 MOSI Pin
*MP3 CS: Chip Select Pin for the audio decoder to be activated while sending control signals.
*MP3 DCS: Chip Select Pin for the audio decoder to be activated while sending audio data signals.
*MP3 RST: Reset pin for the audio decoder.
*MP3 DREQ: Data Request Pin. Audio decoder signals that it is ready to accept next 32 bytes of audio data.
*VCC pin - SJ 3.3V pin
*GND pin - SJ GND Pin

=== Hardware Design ===
[[File:Slide1.png|800x900px|thumb|center|MP3 Decoder Pin Diagram]]

=== Software Design ===

[[File:Mp3_fLow.png|600x500px|thumb|center|MP3 Decoder Software Design]]

=== Implementation ===

We are interfacing MP3 Decoder on the SPI0 for reading the Audio Mp3 file from the SDCard and send Mp3 data to the Decoder. The purpose of this task is to send mp3 data to the mp3 decoder. This is a high priority as it is acting as a consumer. The producer task in our project is the task that reads songs that fill the freeRTOS queue with 4KB of data. The consumer task i.e the task that sends a song to the mp3 decoder that waits on an empty queue for portMAX_DELAY. Once the queue has data, the task starts sending 32 bytes at a time to the MP3 decoder. Once 32 bytes are sent, the task waits for the DREQ pin to get high. DREQ pin high indicates that the MP3 decoder unit is ready to take 32 bytes of data. For sending data, the task acquires the MUTEX so that no other task can use the SPI bus at the same time. Once the 32 bytes are sent, the MUTEX is released. This is the working of the task.

// Task to send data to decoder(High priority)
static uint8_t bytes_to_be_sent_to_decoder[READ_BYTES_FROM_FILE];
static uint8_t current_count = 0;
uint32_t start = 0, end = 0;
while (1) {
if (0 == current_count) {
xQueueReceive(mp3_queue, &bytes_to_be_sent_to_decoder[0], portMAX_DELAY);
}
start = (current_count * TRANSMIT_BYTES_TO_DECODER);
end = ((current_count + 1) * TRANSMIT_BYTES_TO_DECODER);
while (!mp3__dreq_get_status()) {
mp3__decoder_refresh();
vTaskDelay(2);
}
if (xSemaphoreTake(mp3_mutex, portMAX_DELAY)) {
mp3__data_cs();
send_32_bytes_to_decoder_using_ssp(start, end,
&bytes_to_be_sent_to_decoder[0]);
mp3__data_ds();
xSemaphoreGive(mp3_mutex);
if (current_count == COUNT - 1) {
current_count = start = end = 0;
} else {
current_count += 1;
}}}

=='''Audio Frequency Analyzer'''==

In the audio analyser, strobe and reset pins are used to select the DC peak output. Reset high resets the multiplexer. Reset low enables the strobe pin. At the leading edge of the first strobe, the first frequency band 63Hz is on the output. On each additional leading edge strobe the next frequency band(160Hz, 400Hz, 1kHz, 2.5kHz, 6.25kHz, 16kHz) is detected.

This analyser takes input from Audio decoder for left and right side music. SJ2 controls the RS and ST pins of the "Audio Frequency Analyzer" and reads input data from S pin which is connected to ADC pin (P0.26) of SJ2 board.

*Audio Analyzer S pin -> SJ2 ADC4 pin
*Audio Analyzer RS pin -> SJ2 P0.11 pin
*Audio Analyzer ST pin -> SJ2 P2.0 pin
*Audio Analyzer + pin -> SJ2 VCC pin
*Audio Analyzer - pin -> SJ2 GND pin
<div style="clear: both"></div>

====Audio Frequency Analyser====
Audio frequency analyser is working is most important task in order to get correct value. Incorrect initialisation and in efficient delays may cause error. In this project Init and reading of data at each frequncy band is implemented based on timing diagram shown as bellow:

[[File:244 Spark TimingDiagram AudioAnalyser.jpeg|thumb|550x400px|centre|Timing Diagram of Audio Analyser]]

The software Implementation to Init frequency analyser is as follow: 
1. Select ADC pin 
2. Select GPIO pin direction for reset pin and STOBE pin 
3. Reset Audio frequency analyser 

=='''Sensors Interface'''==

We have worked on two sensors for accessing our entertainment box i.e. Gesture Sensor and Accelerometer. The SJ-Two board has both sensors on board sensor which is interfaced on the I2C bus. Accelerometers are electromechanical devices that sense either static or dynamic forces of acceleration. Static forces include gravity, while dynamic forces can include vibrations and movement. The measurements are on 3-axis and these values can be calibrated to find the desired values.

In our project, an accelerometer is for controlling Controls in the MP3 Mode like PLAY,PAUSE,PLAY Next Song and Back to Previous Song.However in Game Mode we are playing our fruit fury game using Orientation sensor for Smashing fruits coming in Directions South East, South West ,North East and North West and We were using Gesture on SJ-Two Board for gesture recognitions Left, Right, UP and Down to change the configuration in MP3 Mode but after implementation we have realised that giving gesture is more complicated then getting signals from orientation.

=== Hardware Design ===

[[File:Sensor.png|800x900px|thumb|center|APDS9960 & MMA8452Q on board Sensors]]

=== Software Design ===

[[File:Sensor_FLow.png|600x500px|thumb|center|MMA8452Q Software Design]]

=== Implementation ===
The MMA8452Q has an orientation detection algorithm with the ability to detect all six orientations but we are using only 4 orientations i.e. Portrait Up, Portrait Down,Landscape Left and Landscape Right .The transition from portrait to landscape is fixed with a 45° threshold angle and a ±14° hysteresis angle. This allows the for a smooth transition from portrait to landscape at approximately 30° and then from landscape to portrait at approximately 60°.

[[File:accel_orient.png|800x900px|thumb|center|Portrait Orientation]]

We have used the following register settings to configure the sensors and getting all 4 directions and Orientation.

[[File:APDS_Register.png|800x900px|thumb|center|Registers of APDS9960]]

 

After reading the registers we are just performing the actions as per the Orientation detected.

[[File:Accel_register.png|800x900px|thumb|center|Registers of MMA8452Q]]

 

void perform_action_on_orientation(void *p)
{
orientation_e value;
while (1)
{
value = GetOrientation();
switch (value)
{
case Portrait_UP: // Prev Song
printf("Direction Left\n");
xSemaphoreGive(sem__prev_song);
break;
case Portrait_DOWN: // Next Song
printf("Direction Right\n");
xSemaphoreGive(sem__next_song);
break;
case Landscape_LEFT: // Resume/Play/
printf("Direction Up\n");
vTaskSuspend(handle__play_song);
vTaskSuspend(handle__freq_bands);
song_status = PLAY;
break;
case Landscape_RIGHT: // Pause/Stop/Volume Decrease
printf("Direction Down\n");
vTaskResume(handle__play_song);
vTaskResume(handle__freq_bands);
song_status = PAUSE;
break;
default:
break;
}
vTaskDelay(50);
}}

=='''Bluetooth Interface'''==
The SJ-two is connected to the Bluetooth module through the Serial interface (UART3) and we have configured it at 38400 baud rate with 8-bit data and 1 stop bit using the Communication Mode. It is used to send and receive the Game and Music data from our entertainment device to an android application.

=== Hardware Design ===

[[File:Slide3.png|700x900px|thumb|center|Bluetooth Interface Pin Diagram]]

===HC-05 Bluetooth module===
HC-05 Bluetooth Module is used to set up wireless communication between the entertainment device and the Android phone. The right section of the Bluetooth Board has connection pins for power and signals as well as a 5V to 3.3V Regulator, LED, and level shifting.

'''HC-05 PinOut'''
* EN: N/A
* VCC: 5V Power
* GND: Ground
* TXD: Serial Transmit pin connected to RXD3 of SJ board
* RXD: Serial Receive pin connected to TXD3 of SJ board
* STATE: States if connected or not

=== Software Design ===

[[File:Bluetooth_Sw_diagram.png|600x500px|thumb|center|Bluetooth Software Design]]

=== Implementation ===

An accelerometer is used in the MP3 Mode to implement functionalities such as play, pause, switch to next and previous songs and volume control. In the game mode the “Fruit fury” game is played by smashing fruits appearing in the directions South East, South West, North East and North West. UART3 is used as communication protocol.The Bluetooth commands that we are using to interact with Mobile app and Device are as follows:

GAMING = 0xA1,
NORTH_EAST = 0x71,
NORTH_WEST = 0x72,
SOUTH_WEST = 0x73,
SOUTH_EAST = 0x74,
MUSIC = 0xA2,
SONG_LIST = 0xA3,
NEXT_SONG = 0xC2,
TOGGLE_SONG = 0xC1,
PREV_SONG = 0xC0,
ACK = 0x00,
NACK = 0xFF,
VOL_INC = 0xB1,
VOL_DEC = 0xB0

=='''Mobile Application'''==

{|
|[[File:Modes.jpeg|230px|thumb|List Of Feature in the APP]]
|[[File:GAME.jpeg|230px|thumb|Game Mode]]
|[[File:Mp3_song.jpeg|230px|thumb|MP3 Mode]]
|[[File:SongList.jpeg|230px|thumb|List Of Songs in SD Card]]
|}

=== Software Design ===

The Android app has been built using the cross platform framework [https://flutter.dev/ Flutter]

The app is composed of 3 parts, '''Game Mode''', '''MP3 Mode''' and '''MP3 Song List'''. On the main screen we first connect to the bluetooth before establishing connection with any of the modes. The working of each mode is explained in each subsection below.

A few variables to note in advance
ACK = 0x00, sent when successful
NACK = 0xFF, sent incase there is any error

====1. Game Mode ====

Wireless communication with the Entertainment box communication over Bluetooth protocol. Android Application is created which provides an interface to exchange data and configure the device.To enter the Game Mode screen we first check if the Bluetooth Connection is established. We send in a one byte data 0xa1 over bluetooth to the SJ2 Board and get back the response "a1$ack/nack$##" We then enter the game mode which displays a joystick that can be oriented to a direction wherever the fruit appears on the LED matrix. The corresponding orientation value is then transmitted.If the fruit had appeared in any of the quadrant then will send data from BLE APP to SJTwo Board.

'''1.''' First Quadrant (North-East): 0x71 
'''2.''' Second Quadrant (North-West): 0x72 
'''3.''' Third Quadrant (South-West): 0x73 
'''4.''' Fourth Quadrant (South-East): 0x74 

====2. MP3 Mode ====

To enter the MP3 Mode screen we first check if the Bluetooth Connection is established similar to the Game Mode. We send in one byte of data 0xa2 over bluetooth to the SJ2 Board and get back the response "a2$ack/nack$volumeInfo$currentSong$isPlaying/isPaused$##" where isPlaying is 1 and isPaused is 0. These values are loaded into the MP3 Mode Screen as initial values for the current song playing. We can then see a screen where we can control the various aspects of playing songs i.e Playing and Pausing the song, Go to next song and and Go to the previous song. We can also control the volume remotely.Controlling each part of this interface is the same as sending a single byte of data over bluetooth to the SJ2 Board.

'''1.''' Playing and Pausing Song - We just toggle the state of the Song. We issue this command by sending 0xc1 which is the Toggle State command. 
'''2.''' Next Song and Previous Song - Command for the previous and next song is 0xC0 and 0xC2. 
'''3.''' Control Volume remotely - For volume we divide the percentage 100 percent in 16 parts. We can send the value between 0xb0 to 0xbf in increments of one step. This is parsed on the SJ2 Board and converted to an equivalent volume signal. 

====3. MP3 Song List ====
To get the list of MP3 Songs which are present in the SD card, we first check if the Bluetooth Connection is established similar to the Game Mode and MP3 Song mode. We send in one byte of data 0xa3 over bluetooth to the SJ2 Board and get back the response "a3$ack/nack$data$data$...$##". APIs that were designed to read song information and data by Audio Decoder, will be used for achieving this functionality.

=='''OLED Screen'''==

=== Software Design ===

The open source package [https://github.com/olikraus/u8g2 u8g2] has been used.
There are already ready made functions for various OLED Drivers. The indepth setup guide can be found [https://github.com/olikraus/u8g2/wiki/u8g2setupc here]

=== Implementation ===

The u8g2 library is a very robust library which means that this code can be extended for any microcontroller as long as the interface is written properly.

We needed to write 2 main functions, outlined below, i.e byte_cb and gpio_and_delay_cb using the function prototype `uint8_t u8x8_lpc_gpio_and_delay(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr)`.

Since the SJ2 Board is connected to the OLED Screen on the SPI1 Bus we also need to write the SPI1 driver, mainly a method to that sends data over SPI to the Slave device i.e the OLED Screen

=== Initializing the u8g2 for LPC4078 ===

<source lang="cpp">

// Created a file `u8g2_wrapper.h

static gpio_s dc;
static u8g2_t u8g2;

void u8g2_wrapper__init(gpio_s *dc_pin) {
u8g2_Setup_ssd1306_128x64_vcomh0_1(&u8g2, U8G2_R0, u8x8_byte_4wire_hw_spi, u8x8_lpc_gpio_and_delay);
u8g2_InitDisplay(&u8g2);
u8g2_SetPowerSave(&u8g2, 0);

dc.pin_number = dc_pin->pin_number;
dc.port_number = dc_pin->port_number;
}

u8g2_t *u8g2_wrapper__get_instance() { return &u8g2; }

uint8_t u8x8_lpc_gpio_and_delay(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr) {
switch (msg) {
case U8X8_MSG_GPIO_AND_DELAY_INIT:
delay__ms(1);
break;
case U8X8_MSG_DELAY_MILLI:
delay__ms(arg_int);
break;
case U8X8_MSG_GPIO_DC:
// DONE, Write to the GPIO_DC Pin
if (arg_int == 0) {
gpio__reset(dc);
} else {
gpio__set(dc);
}
break;
case U8X8_MSG_GPIO_RESET:
break;
}
return 1;
}

uint8_t u8x8_byte_4wire_hw_spi(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr) {
uint8_t *data;
switch (msg) {
case U8X8_MSG_BYTE_SEND:
data = (uint8_t *)arg_ptr;
while (arg_int > 0) {
ussp1__exchange_byte((uint8_t)*data);
data++;
arg_int--;
}
break;
case U8X8_MSG_BYTE_INIT:
break;
case U8X8_MSG_BYTE_SET_DC:
if (arg_int == 0) {
gpio__reset(dc);
} else {
gpio__set(dc);
}
break;
case U8X8_MSG_BYTE_START_TRANSFER:
break;
case U8X8_MSG_BYTE_END_TRANSFER:
break;
default:
return 0;
}
return 1;
}

</source>

=='''Technical Challenges'''==

1. '''RGB LED Matrix''' 

* Getting control of the matrix was challenging as it needs to follow specific sequence of pin enabling/disabling at appropriate timing.

* Setting right delays to avoid flickers and get smooth transitioning between frames by using delays or for loops.

* Fixing high CPU utilization by changing delay__us to vTaskDelay.

* Designing elements of the game (title screen and fruit objects) which required careful plotting of pixel data.

2. '''Audio Decoder''' 

a) The CPU utilization for sending a song task was very high (80% +).
* In order to reduce the utilization, we gave the vTaskDelay(1) while waiting for the DREQ to be high. The high DREQ indicates that the decoder is ready to receive next 32 bytes of data. So meanwhile, when the DREQ pin is low, we made task to sleep for vTaskDelay(1). After doing this, we significantly reduced the CPU utilization to 15%. We tried with vTaskDelay(2) to get CPU utilization of 10%.
* We further tried to make the CPU utilization below 10%. This was really a tough challenge, and figured out that the actual SPI clock is 1Mhz which is too slow as SPI is meant to operate at much higher speed. We changed the clock rate of SPI to 12MHz but the song speed was too slow. We checked the datasheet of the Mp3 decoder and set the internal clock multiplier to 4.5x. This make the shield operate at high clock rates at 12.XX Mhz. So keeping this in mind we made the SPI speed to 12MHz which is safe. We successfully achieved CPU utilization of 5-6% which is very much in the acceptable range.

3. '''PCB Designing''' 

* We realized that using GPP for long term is not a good idea. Initially we spent time in debugging our hardware and later we have realized like we can’t take this for our final day.
* We did multiple reviews before ordering our final PCB as none of us did that earlier. We have faced issue in manual routing on Eagle Autodesk but our ISA Prashant helped us and he reviewed our PCB design twice.

4. '''Mobile Application''' 

* The main challenge of the Mobile application was to make the UI interactive while getting data asynchronously over the Bluetooth module.
* There was a global listener stream implemented that got the value and concatenate the string till we received the end frame (##).
* However the challenge still existed to know which screen has called what data which prompted us to create the key and ACK/NACK pair in the start.
* The Mobile app is completely data reactive, which means that the UI components render and change according to the data provided. This caused a lot of issues mainly since we tried polling methods to make sure that the UI remains up to date with the STATE of the SJ2 Board.
* A manual approach was opted for mainly to make the system more deterministic and for better debugging capabilities.

=='''Suggestions for Future Students'''==
 '''RGB LED Matrix''' 

* To begin with, focus on writing a simple driver to get control of 1 pixel at a targeted location and then use appropriate loops to light up the entire row/column.

* Make sure all pixels are able to light up with all possible colors to eliminate hardware defects.

* Try with minimum / no delays, print tick counts and then come up with meaningful delay numbers.

* Optimize the code (minimum delays, avoiding repetitive function calls, etc.) to bring down the CPU usage level.

* Use the link in the references to draw desired elements and generate the matrix.

 '''Tips for getting GOOD Grades and to remain in top 3 teams''' 
* Select your teammates wisely, and make sure every one dedicates themself for this project.
* Be an active member of your team and review rubrics for the final DEMO.
* As soon as the professor mentions the project, please start working on the project otherwise, in the end, you have to struggle with finals and you will be left with less time for testing and you have to struggle in demo.

 '''General tips''' 
* Remember the KISS approach when you code. (Keep It Simple and Stupid).
* For this project, one should know the basics in C/ C++, FreeRTOS, and some good debugging skills. Because if you don't have one, you will eventually end up spending more time debugging your problem.
* Always give meaningful names to the variable or the function, so a third person reviewing the code gets an overall idea by just reading the name.

=='''Conclusion'''==
It was a really great working experience for all of us. We were really thrilled from the beginning that we will be working on something that is quite relevant in the industries. We worked as a team of four which helped us all to know the importance of team-work and co-ordination. We learned many great stuff like

* State Design using FreeRTOS
* FreeRTOS APIS when task handles are NULL vs when Initialised.
* Uses of extern and global variables as opposed to encapsulation i.e static inside private 'c' files.
* Learning Optimization through the integration of our peer's individual modules
* Improving CPU utilisation of the main LED and MP3 tasks.
* Workload sharing and cooperation amongst peers.
* Sharing ideas and debugging a common problem together i.e team building.
* We realised that using GPP for long term is not a good idea, there were some breakdown in the wires and our MP3 stopped working. Initially we spent a lot of time debugging hardware and doing soldering. So we started designing the PCB, and when our PCB was done, we spent hardly any time debugging the hardware.
* Git : We learnt all the basic of GIT and it plays an important to role for source code versioning.

There were a lot of problems while doing this project but it was a steep learning curve. In the end we were able to achieve our objective with really good results.

=='''Project Video'''==
https://youtu.be/vVjHCoyWYz4

=='''Project Source Code'''==
* Git Project Link (Individual Modules): [https://gitlab.com/Infinity_Mirror/infinity_mirror-cmpe-244]
* Git Project Link: [https://gitlab.com/ganeshram2493/infi_mirror]

=='''Project Presentation File'''==
* [https://drive.google.com/file/d/1Q_Xvs-a2feQcr-FbPEKbwmlhi35hqNxX/view?usp=sharing Presentation Link]

=='''References'''==
=== Acknowledgement ===

We would like to express our gratitude to Professor Preetpal Kang for generously sharing his time and knowledge with us and guiding us through the completion of this project. We would also like to thank the Prashant Gandhi(ISA) for their valuable advice and constructive feedback.

=== References Used ===

====== Flutter Android GUI ======
* [https://material.io/resources/icons/?style=baseline Material Design Icons]
* [https://flutter.dev/ Building a Dynamic UI with Flutter]
* [https://www.youtube.com/channel/UCwXdFgeE9KYzlDdR7TG9cMw Flutter Youtube Channel]

====== RGB LED Matrix Interfacing and Designing ======
* [https://www.sparkfun.com/products/14718 Datasheet and Hookup guide]
* [https://cdn-learn.adafruit.com/downloads/pdf/32x16-32x32-rgb-led-matrix.pdf?timestamp=1543806512/ Wiring and pin information]
* [https://www.riyas.org/2013/12/online-led-matrix-font-generator-with.html Hex code generator to build LED matrix models]

====== MP3 Decoder and Frequency Analyzer ======
* [https://www.sparkfun.com/datasheets/Components/General/MSGEQ7.pdf Seven Band Graphic Equalizer MSGEQ7 Data Sheet]
* [https://www.kr4.us/SparkFun-MP3-Player-Shield.html?gclid=EAIaIQobChMIov3f7PWc2wIVDtVkCh0-rgStEAYYASABEgIEgPD_BwE SparkFun-MP3-Player-Shield Datasheet]

====== Gesture & Orientation Sensors ======
* [https://cdn.sparkfun.com/assets/learn_tutorials/3/2/1/Avago-APDS-9960-datasheet.pdf Gesture Sensor Data Sheet]
* [https://learn.sparkfun.com/tutorials/mma8452q-accelerometer-breakout-hookup-guide/all Accelerometer Sensor Data]

====== General/Miscellaneous ======
* [http://socialledge.com/sjsu/index.php/FreeRTOS_Tutorial FreeRTOS Tutorial]
* [https://sjsu-dev2.readthedocs.io/en/latest/?badge=latest SJTwo-c Documentation]

F19: Infinity Mirror

2019-12-18T22:17:02Z

Proj user22: /* Project Video */

== '''Abstract''' ==

The main theme of the project is to build an interactive embedded system consisting of two entertainment modes - Music and Gaming. On the music mode, the MP3 decoder module reads songs from an SD card on the MCU board and plays the music through a speaker. It deals with the convergence of various services such as playing a game with background music, control volume, switch and pause/play songs. While the song is being played, audio frequency spectrum bands based on music tune are displayed on the LED Matrix band visualization etc. On the game mode, a fruit smashing game called “Fruit Fury” is implemented where the user needs to orient the MCU board in a direction according to where the fruit appears on the LED matrix. Alongside, the user can listen and switch songs. To achieve the above functionalities, various elements such as Audio Decoder, Audio frequency analyzer, 32x64 RGB LED Matrix and HC-05 bluetooth module and Android application are integrated.

[[File:High_level1.png|800px|thumb|center|Block Diagram of Infinity Mirror]]

== '''Introduction & Objectives''' ==

The key features supported by the system is real-time orientation recognition & trigger respective actions in 2 modes - MP3 mode and Game mode.

MP3 MODE:

1. Determine the accelerometer sensor values based on the orientation of the board and perform music control such as play, pause, volume control and changing songs.

2. In response, retrieve the data from the SD Card & communicate to the audio decoder for appropriate audio streaming.

3. Also implemented interaction with HC-05 bluetooth module through a customized mobile application and provide same operations.

4. Display frequency spectrum bands in sync to the tune of the song played.

GAME MODE - Fruit Fury:

1. Determine the accelerometer sensor values based on the orientation of the board and hit the fruit in corresponding direction.

2. Incorporating provision on the board's switches to change to next or previous song.

3. Also implemented interaction with HC-05 bluetooth module through a customized mobile application and play the game through the same.

'''Project Objectives'''
'''1. Audio Decoder''' - Fetches song data from the SD card and plays it over a speaker.
'''2. RGB LED Matrix''' - Display frequency bands on music mode or view the game on game mode.
'''3. Audio Frequency Analyzer''' - To convert the audio data into 7 spectrum bands which is then displayed as individual colored bands on the LED matrix.
'''4. Bluetooth HC-05''' - Interfaces the system using Bluetooth to an Android application.

'''Team Objectives'''
'''1.''' Learn each and every module as much as possible, in order to develop an overall product.
'''2.''' Understand the proper use of queues and semaphores in order to send/receive the data between multiple tasks.
'''3.''' Learn to integrate all modules and ensuring smooth transition, communication and context switching at desired time intervals.
'''4.''' Document and track all the bugs encountered during development and learn to update git repository after every fix.

== '''Team Members & Technical Responsibilities''' ==
[[File:cmpe244_F19_Infinity_Mirror_members.jpeg|thumb|500x500px|TEAM INFINITY MIRROR|right]]

*'''''[http://linkedin.com/in/aakash-chitroda-17841740 Aakash Chitroda]'''''
** MP3 Audio Encoder/Decoder
** Audio frequency Analyzer logic

*'''''[https://www.linkedin.com/in/ganeshram93 Ganesh Ram]'''''
** Interfacing of LED Matrix and driver design
** Game logic design
** Audio frequency spectrum logic on LED
** Packaging

*'''''[https://www.linkedin.com/in/niket-naidu-30090a134/ Niket Naidu]'''''
** Android & Bluetooth Application
** OLED Interfacing and Designing
** PCB Design improvements
** Accelerometer Sensor integration with OLED Screen

*'''''[https://www.linkedin.com/in/vidushi-jain-048b992a Vidushi Jain]'''''
** Bluetooth Communication
** Interfacing of Gesture & Accelerometer Sensors
** Hardware Designing & PCB Integration

 

== '''Administrative Responsibilities''' ==
{| class="wikitable" style="margin-left: 0px; margin-right: auto;"
|- style="vertical-align: top;"
! colspan="5" style="background:#588ecc" | Administrative Roles 
|-
! style="text-align: left;" |
* Team Lead 
| Aakash Chitroda 
|-
! style="text-align: left;" |
* Finance Manager
| Niket Naidu 
|-
! style="text-align: left;" |
* Git Repository Manager 
| Vidushi Jain 
|-
! style="text-align: left;" |
* Wiki Report Manager 
| Vidushi Jain 
 Ganesh Ram 
|-
! style="text-align: left;" |
* Bill of Materials Manager 
| Ganesh Ram 
|}

== '''Team Deliverables Schedule''' ==

{| class="wikitable"
|-
! scope="col" style="text-align: left;" style="background:#588ecc;" | WEEK
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
START DATE 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
END DATE 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
TASK DETAILS 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
STATUS 
|-
| 1 || 15 Oct 2019 || 22 Oct 2019 ||
*Create and establish GitLab repository
*Establish slack channel and invite Preet
*Look through previous years projects and study it
*Distribute major roles among team members
|| Completed Completed Completed Completed 
|-
| 2 || 23 Oct 2019 || 29 Oct 2019 ||
* Create a Bill of Materials 
* Select and order Parts 
* Review Data-sheet and Interfacing Of LED Matrix(Ganesh) 
* Review Data-sheet for Gesture sensor(Vidushi) 
* Make Repo on Gitlab for all modules - Follow Naming Convention. 
|| Completed Completed Completed Completed Completed 
|-
| 3 || 30 Oct 2019 || 5 Nov 2019 ||
* Review Data-sheet of Audio MP3 shield(Aakash) 
* Start Soldering for LED matrix and MP3 Shield 
* Start Soldering of Headers for MP3 Shield & decoder
* Environmental setup of Android & Web applications(Niket) 
* Implementation of Gesture Detection (Vidushi)
* Implementation of displaying text and basic shapes on LED Matrix (Ganesh)
|| Completed Completed Completed Completed Completed Completed 
|-
| 4 || 6 Nov 2019 || 12 Nov 2019 ||
* Implementation of OLED Driver(Niket)
* Initialization the Audio Decoder through SPI communication and read manufacturer ID 
* Implementation of random frequency bands on LED matrix (Ganesh)
* Implementation of communication Between two task(gesture_detect & LED_Display) using queues and semaphores (Vidushi)
* Display Gesture Sensor Directions on OLED in a Text (Vidushi & Niket)
* Read Song from SD Card 
|| Completed Completed Completed Completed Completed Completed 
|-
| 5 || 13 Nov 2019 || 19 Nov 2019 ||
* Circuit Simulation in Diptrace/Eagle Tool. 
* PCB Layout Design in Diptrace/Eagle Tool. 
* Finalize Components placement on PCB. 
* Read Song from SD Card and send to MP3 Shield 
* Receive Values from audio spectrum and send to display task to display on LED Matrix.(Aakash & Ganesh) 
* Interface OLED with onboard buttons to access the list of songs (Niket)
* Developing logic for the ball movement and translating hand-gesture control into LED movement.(Ganesh)
|| Completed Completed Completed Completed Completed Completed Completed 
|-
| 6 || 20 Nov 2019 || 26 Nov 2019 ||
* Interfacing of all modules sensors, bluetooth , MP3 and LED Matrix
* Test whole implementation after integration of all modules
* Test for stack overflow and system crash
* Debug and Test the Play/Pause/Stop functionality of MP3 player 
* Integrate fruit Fury game logic
* Update Final Wiki Schedule. 
|| Completed Completed Completed Completed Completed Completed Completed 
|-
| 8 || 27 Nov 2019 || 3 Dec 2019 ||
* Additional Feature week
* Establish Bluetooth communication of Device and Mobile APP 
* Develop UI on Android application. 
* Add Play/Pause/Stop and Song selection functionality to the APP. 
* Update Wiki with new details and information. 
* Enhanced game logic and integrated song play feature in game 
|| Completed Completed Completed Completed Completed 
|-
| 9 || 4 Dec 2019 || 10 Dec 2019 ||
* TESTING - CRITICAL WEEK 
* Packaging of hardware board and related components. 
* Check overall robustness of the complete system. 
* Establish complete connection on PCB 
* Update wiki with details. 
|| Completed Completed Completed Completed Completed 
|-
| 10 || 11 Dec 2019 || 17 Dec 2019 ||
* All hands on testing and final bug fixes. 
* Check for tuning or calibration of sensors if required. 
* Complete end-to-end testing for various scenarios and conditions. 
* Create the semester long project activity video and upload to YouTube. 
* Update and finalize wiki. 
|| Completed Completed Completed Completed Completed 
|-
| 11 || 18 Dec 2019 || ||
* '''DEMO: Final Project''' 
* '''SUBMISSION: Final Project Wiki''' 
|| Completed Completed 
|}

== '''Bill of Materials (General Parts)''' ==

{| class="wikitable"
|-
! scope="col" style="text-align: left;" style="background:#588ecc;" | PART NAME 

! scope="col" style="text-align: left;" style="background:#588ecc;" | 
PART MODEL & SOURCE 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
QUANTITY 
! scope="col" style="text-align: left;" style="background:#588ecc;" | 
COST PER UNIT (USD) 
|-
|
* Micro-Controller Eval-Boards
|
* LPC 4078 (Purchased from Preet Kang)
|
* 1
|
* 50.00

|-
|
* Audio decoder Breakout Board
|
* [https://www.sparkfun.com/products/12660 SparkFun MP3 Player Shield]
|
* 1
|
* 26.95

|-
|
* Audio Analyzer
|
* [https://www.amazon.com/dp/B074T9H8JV/ DFR0126 Audio Analyzer]
|
* 1
|
* 19.00

|-
|
* RGB LED matrix
|
* [https://www.sparkfun.com/products/14718 32 x 64 RGB LED Matrix Panel]
|
* 1
|
* 49.95

|-
|
* Power supply
|
* [https://www.sparkfun.com/products/15352 5V / 4A Power Supply]
|
* 1
|
* 12.95

|-
|
* Audio Speakers
|
* 3.5mm Jack Stereo Speakers
|
* 1
|
* Own

|-
|
* PCB parts and other Miscellaneous parts
|
* Anchor Electronics and Digikey '''
|
* 1
|
* 50.00

|-
|
* 2 way mirror
|
* [https://www.amazon.com/gp/product/B06Y2C79FC/ref=ppx_yo_dt_b_asin_title_o03_s00?ie=UTF8&psc=1 2-way mirror ]
|
* 1
|
* 7.64

|-
|
* PCB Fabrication
|
* [https://jlcpcb.com/quote JLCPCB]
|
* 5
|
* 29.53
|}

 

== '''Printed Circuit Board''' ==

=== Design And Architecture ===

We have designed the custom PCB using Eagle Software and as well as one prototype board in which we have connected all the modules with SJ-Two board. PCB was sent to fabrication to JLCPCB China which provided PCB with lead time of 1 week. We have implemented 2 layers of PCB with all of the parts in top layer.

'''Components Placements on PCB and on Prototype Board'''
'''1.''' One SJ-Two board is fitted onto the top of the 3D printed lid cover which with a slot opening for 2x40 IDC cable.
'''2.''' MP3 Decoder is connected with SJ-Two board and will be place on the right side of PCB and as well as on Prototype board.
'''3.''' Bluetooth Module needs only 4 pins to connect with SJ-Two and goes to UART3 and placed on the top left of the board.
'''4.''' LED Matrix is connected using 2x8 IDC cable pins on the top left side of the board.
'''5.''' Audio Frequency Analyzer is placed on the bottom side of PCB.
'''6.''' Power supply of 5v and 3.3v provisions are made on the bottom left side of PCB.

{|
[[File:Top_Layout.png|500x600px|thumb|left|Top Layer PCB Design On Eagle Software]]
|[[File:Bottom_Layout.png|500x600px|thumb|right|Bottom Layer PCB Design on Eagle Software]]
|}

{|
[[File:Top_View.png|500x600px|thumb|left|PCB Top Layer]]
|[[File:Bottom_View.png|500x600px|thumb|right|PCB Bottom Layer]]
|}

'''Infinity Mirror's Internal Circuit'''

[[File:Setup.jpeg|thumb|350x350px|center|Infinity Mirror: Internal Circuit of Embedded Entertainment Box]]

=='''Product Enclosure''' ==

To facilitate easy and convenient gaming experience and also act as an effective audio controller, a single 3D printed enclosure was designed which is spacious enough to accommodate the MCU modules like bluetooth, audio frequency analyzer and MP3 decoder on the PCB.

{|
|[[File:Top.jpeg|470px|thumb|left|Top View]]
|[[File:3D.png|430px|thumb|right|3D View]]
|}

===Final 3D Package===
[[File:Final_Setup.jpeg|thumb|600x600px|center|Infinity Mirror: Final Setup]]

=='''RGB LED Matrix'''==
A 32 x 64 RGB LED Matrix will be powered up through a 5V/4A DC adapter and is interfaced with the board to play the game 'Fruit Fury' with desired background song in the game-mode and to display the frequency bands and other relevant messages such as "Next", "Previous" and "Pause" in the music-mode. Only the INPUT IDC connector will be used because we are not cascading multiple matrices. The matrix has 2 planes (upper and lower), both of which will be programmed separately. In order to set RGB color data for each pixel in plane 1 (top half of the display) we use R1, G1 and B1 pins and for plane 2 we use R2, G2 and B2. By setting and resetting the CLOCK pulse, color data is set for every pixel in the row. Then the LATCH is set to mark end of the row and reset to move to next row. All of these steps are repeated at very less time intervals so that the human eye perceives it as one complete frame (Persistence of Vision).

Below is the description of the pins:

*R1 -> Sets upper panel's Red data
*G1 -> Sets upper panel's Green data
*B1 -> Sets upper panel's Blue data
*R2 -> Sets lower panel's Red data
*G2 -> Sets lower panel's Green data
*B2 -> Sets lower panel's Blue data
*A -> Sets row bit 0
*B -> Sets row bit 1
*C -> Sets row bit 2
*D -> Sets row bit 3
*CLK (Clock) -> Set to access each pixel
*LAT (Latch) -> Set to mark comletion of one row
*nOE (Output Enable) -> Set to switch the LEDs off when transitioning from one row to the next
*GND -> Ground pins to be connected with board's GND.

Below are the technical specifications:

*Pitch -> 4 mm
*Resolution -> 32 x 64 = 2048 dots
*Panel dimensions (l x b x h) in mm -> 256 x 128 x 13
*Working voltage/current rating -> 5v / 4A (max)
*Scan rate - 1/16
*Pixel component configuration (R,G,B) -> 1,1,1
*Weight -> 0.24 kg

=== Hardware Design ===
The hardware involves 5V/4A DC power supply adapter, barrel jack connectors and IDC cables to power up the LED matrix and communicate with the board. Below is the pin interfacing diagram.
[[File:Slide2.png|700x900px|thumb|center|LED Matrix Pin Diagram]]

=== Software Design ===
1. '''Fruit Fury - Game mode''' 

There are 2 tasks involved to ensure functioning of the game.

a) Task 1:
*Display the game's title screen. On pressing the onboard switch (SW1), game begins.
*Also used to display game over screen / win screen.
b) Task 2:
*Enter into game mode to play the game.
*Read accelerometer values (board orientation) and render game frame.
*Detect the player's board movement, compare it with fruit's location.
*Display score, lives and smash effects.
*Press another switch (SW0) to stop game and return to title screen or to restart the game once it is over.

 '''Game rules:''' 

a) Game comprises of 3 levels (level 2 on reaching score 15 and level 3 on reaching score 30) and 5 lives in total.

b) Primary objective is to tilt the board to the direction (North West, North East, South West or South East) in which the fruit appears in order to smash it.

c) Score increases by 1 point for smashing each fruit.

d) Bombs start appearing after completion of level 1, which costs a life when hit.

e) Level 3 is faster so make sure you tune your reflexes up.

f) Reach score 50 to win the game.

 '''Bonus:''' 

a) Streaks are rewarding. Smash 10 fruits straight up to win an extra life.

b) Look out for star fruits. Hit them to gain +2 points.

Choose your song to take all the inspiration you can and start smashing!

 '''2. Music mode''' 

a) Press the button to enjoy music-only mode. Graceful audio spectrum bands are displayed that dance to the tune of the chosen song.

b) A display is prompted to the user whenever music is paused or changed to next or previous song.

=== Implementation ===
'''LED Driver'''

1. Initialize the LED matrix by configuring necessary pin directions.

2. Disable Output Enable (OE) GPIO before feeding matrix data.

3. Select the required row by setting bits on A, B, C, D GPIO pins.

4. Loop through the pixels (columns) in the selected row and set the pixel color on R, G, B GPIO pins.

5. Set zero on R, G, B GPIO pins to mask that particular pixel.

6. Set and Reset the clock for pushing the R, G, B bits for each column.

7. Issue latch to mark the row's completion and reset latch before going to next row.

8. Follow the steps 2 to 7 for other rows.

<source lang="cpp">
for (uint8_t row = 0; row < (MAX_ROW / 2); row++) {
disableOE();
set_row(row);
for (uint8_t col = 0; col < MAX_COL; col++) {
LPC_GPIO0->PIN |= (1 << CLK);
set_color_bottom(game_matrix[row + (MAX_ROW / 2)][col]);
set_color_top(game_matrix[row][col]);
LPC_GPIO0->PIN &= ~(1 << CLK);
}
LPC_GPIO0->PIN |= (1 << LAT);
LPC_GPIO0->PIN &= ~(1 << LAT);
enableOE();
vTaskDelay(1);
}
</source>

'''Fruit Fury - Game mode'''

1. Generate the fruit's initial coordinate using random function (used srand() with time value as seed to get random pattern sets).

2. Construct the LED matrix array by drawing the fruit and borders.

3. Push the entire matrix data to LED driver to display the constructed matrix frame.

4. Then read the player's orientation and match with fruit's direction.

5. Modify game parameters (score, lives and level) based on player's results.

6. Stop game if all lives are over and display game over screen by switching to game init task (Task 1).

<source lang="cpp">
/* Push button to exit game */
if (LPC_GPIO0->PIN & (1 << SW0))
is_start_game = false;

if (is_start_game == true) {
/* Generate fruit's initial coordinate position */
get_fruit_begin_coord(&row_pt, &col_pt, &quadrant);
/* Generate final frame by considering fruit object at that position */
construct_game_matrix(row_pt, col_pt);
/* Draw final frame matrix of the game */
draw_final_game_frame();
/* Get the board direction from the user and increment score count */
compute_game_params(row_pt, col_pt, quadrant);
} else
vTaskResume(display_game_init_screen_t);
</source>

'''Spectrum display - Music mode'''

1. Read the audio frequency values from the graphic equalizer task and store it as an array.

2. Based on value of each frequency band, assign a height of the band (in pixels) to be drawn on the LED matrix.

3. Set a unique color for each band.

3. Push the entire matrix data to LED driver to display the constructed matrix frame.

4. Repeat steps 1 to 3 at required intervals to display repeating bands.

<source lang="cpp">

for (row = MAX_ROW - 1; row >= 1; row--) {
for (col = 7; col <= 62; col++) {
if ((row >= (MAX_ROW - band_height[0])) && col >= 7 && col <= 13 &&
band_num <= 0) {
band_matrix[row][col] = RED;
}
if ((row >= (MAX_ROW - band_height[1])) && col >= 14 && col <= 20 &&
band_num <= 1) {
band_matrix[row][col] = GREEN;
}
if ((row >= (MAX_ROW - band_height[2])) && col >= 21 && col <= 27 &&
band_num <= 2) {
band_matrix[row][col] = YELLOW;
}
if ((row >= (MAX_ROW - band_height[3])) && col >= 28 && col <= 34 &&
band_num <= 3) {
band_matrix[row][col] = BLUE;
}
if ((row >= (MAX_ROW - band_height[4])) && col >= 35 && col <= 41 &&
band_num <= 4) {
band_matrix[row][col] = PURPLE;
}
if ((row >= (MAX_ROW - band_height[5])) && col >= 42 && col <= 48 &&
band_num <= 5) {
band_matrix[row][col] = CYAN;
}
if ((row >= (MAX_ROW - band_height[6])) && col >= 49 && col <= 55 &&
band_num <= 6) {
band_matrix[row][col] = WHITE;
}
}
}

</source>

=='''MP3 Decoder'''==

The Audio Decoder breakout board communicates with the SJ board over SPI and is interfaced with the SPI-0 pins of the SJ board as follows:

*Clock Pin (Pin 13) - SJ SPI-0 Clock Pin
*MISO Pin (Pin 12) - SJ SPI-0 MISO Pin
*MOSI Pin (Pin 11) - SJ SPI-0 MOSI Pin
*MP3 CS: Chip Select Pin for the audio decoder to be activated while sending control signals.
*MP3 DCS: Chip Select Pin for the audio decoder to be activated while sending audio data signals.
*MP3 RST: Reset pin for the audio decoder.
*MP3 DREQ: Data Request Pin. Audio decoder signals that it is ready to accept next 32 bytes of audio data.
*VCC pin - SJ 3.3V pin
*GND pin - SJ GND Pin

=== Hardware Design ===
[[File:Slide1.png|800x900px|thumb|center|MP3 Decoder Pin Diagram]]

=== Software Design ===

[[File:Mp3_fLow.png|600x500px|thumb|center|MP3 Decoder Software Design]]

=== Implementation ===

We are interfacing MP3 Decoder on the SPI0 for reading the Audio Mp3 file from the SDCard and send Mp3 data to the Decoder. The purpose of this task is to send mp3 data to the mp3 decoder. This is a high priority as it is acting as a consumer. The producer task in our project is the task that reads songs that fill the freeRTOS queue with 4KB of data. The consumer task i.e the task that sends a song to the mp3 decoder that waits on an empty queue for portMAX_DELAY. Once the queue has data, the task starts sending 32 bytes at a time to the MP3 decoder. Once 32 bytes are sent, the task waits for the DREQ pin to get high. DREQ pin high indicates that the MP3 decoder unit is ready to take 32 bytes of data. For sending data, the task acquires the MUTEX so that no other task can use the SPI bus at the same time. Once the 32 bytes are sent, the MUTEX is released. This is the working of the task.

// Task to send data to decoder(High priority)
static uint8_t bytes_to_be_sent_to_decoder[READ_BYTES_FROM_FILE];
static uint8_t current_count = 0;
uint32_t start = 0, end = 0;
while (1) {
if (0 == current_count) {
xQueueReceive(mp3_queue, &bytes_to_be_sent_to_decoder[0], portMAX_DELAY);
}
start = (current_count * TRANSMIT_BYTES_TO_DECODER);
end = ((current_count + 1) * TRANSMIT_BYTES_TO_DECODER);
while (!mp3__dreq_get_status()) {
mp3__decoder_refresh();
vTaskDelay(2);
}
if (xSemaphoreTake(mp3_mutex, portMAX_DELAY)) {
mp3__data_cs();
send_32_bytes_to_decoder_using_ssp(start, end,
&bytes_to_be_sent_to_decoder[0]);
mp3__data_ds();
xSemaphoreGive(mp3_mutex);
if (current_count == COUNT - 1) {
current_count = start = end = 0;
} else {
current_count += 1;
}}}

=='''Audio Frequency Analyzer'''==

In the audio analyser, strobe and reset pins are used to select the DC peak output. Reset high resets the multiplexer. Reset low enables the strobe pin. At the leading edge of the first strobe, the first frequency band 63Hz is on the output. On each additional leading edge strobe the next frequency band(160Hz, 400Hz, 1kHz, 2.5kHz, 6.25kHz, 16kHz) is detected.

This analyser takes input from Audio decoder for left and right side music. SJ2 controls the RS and ST pins of the "Audio Frequency Analyzer" and reads input data from S pin which is connected to ADC pin (P0.26) of SJ2 board.

*Audio Analyzer S pin -> SJ2 ADC4 pin
*Audio Analyzer RS pin -> SJ2 P0.11 pin
*Audio Analyzer ST pin -> SJ2 P2.0 pin
*Audio Analyzer + pin -> SJ2 VCC pin
*Audio Analyzer - pin -> SJ2 GND pin
<div style="clear: both"></div>

====Audio Frequency Analyser====
Audio frequency analyser is working is most important task in order to get correct value. Incorrect initialisation and in efficient delays may cause error. In this project Init and reading of data at each frequncy band is implemented based on timing diagram shown as bellow:

[[File:244 Spark TimingDiagram AudioAnalyser.jpeg|thumb|550x400px|centre|Timing Diagram of Audio Analyser]]

The software Implementation to Init frequency analyser is as follow: 
1. Select ADC pin 
2. Select GPIO pin direction for reset pin and STOBE pin 
3. Reset Audio frequency analyser 

=='''Sensors Interface'''==

We have worked on two sensors for accessing our entertainment box i.e. Gesture Sensor and Accelerometer. The SJ-Two board has both sensors on board sensor which is interfaced on the I2C bus. Accelerometers are electromechanical devices that sense either static or dynamic forces of acceleration. Static forces include gravity, while dynamic forces can include vibrations and movement. The measurements are on 3-axis and these values can be calibrated to find the desired values.

In our project, an accelerometer is for controlling Controls in the MP3 Mode like PLAY,PAUSE,PLAY Next Song and Back to Previous Song.However in Game Mode we are playing our fruit fury game using Orientation sensor for Smashing fruits coming in Directions South East, South West ,North East and North West and We were using Gesture on SJ-Two Board for gesture recognitions Left, Right, UP and Down to change the configuration in MP3 Mode but after implementation we have realised that giving gesture is more complicated then getting signals from orientation.

=== Hardware Design ===

[[File:Sensor.png|800x900px|thumb|center|APDS9960 & MMA8452Q on board Sensors]]

=== Software Design ===

[[File:Sensor_FLow.png|600x500px|thumb|center|MMA8452Q Software Design]]

=== Implementation ===
The MMA8452Q has an orientation detection algorithm with the ability to detect all six orientations but we are using only 4 orientations i.e. Portrait Up, Portrait Down,Landscape Left and Landscape Right .The transition from portrait to landscape is fixed with a 45° threshold angle and a ±14° hysteresis angle. This allows the for a smooth transition from portrait to landscape at approximately 30° and then from landscape to portrait at approximately 60°.

[[File:accel_orient.png|800x900px|thumb|center|Portrait Orientation]]

We have used the following register settings to configure the sensors and getting all 4 directions and Orientation.

[[File:APDS_Register.png|800x900px|thumb|center|Registers of APDS9960]]

 

After reading the registers we are just performing the actions as per the Orientation detected.

[[File:Accel_register.png|800x900px|thumb|center|Registers of MMA8452Q]]

 

void perform_action_on_orientation(void *p)
{
orientation_e value;
while (1)
{
value = GetOrientation();
switch (value)
{
case Portrait_UP: // Prev Song
printf("Direction Left\n");
xSemaphoreGive(sem__prev_song);
break;
case Portrait_DOWN: // Next Song
printf("Direction Right\n");
xSemaphoreGive(sem__next_song);
break;
case Landscape_LEFT: // Resume/Play/
printf("Direction Up\n");
vTaskSuspend(handle__play_song);
vTaskSuspend(handle__freq_bands);
song_status = PLAY;
break;
case Landscape_RIGHT: // Pause/Stop/Volume Decrease
printf("Direction Down\n");
vTaskResume(handle__play_song);
vTaskResume(handle__freq_bands);
song_status = PAUSE;
break;
default:
break;
}
vTaskDelay(50);
}}

=='''Bluetooth Interface'''==
The SJ-two is connected to the Bluetooth module through the Serial interface (UART3) and we have configured it at 38400 baud rate with 8-bit data and 1 stop bit using the Communication Mode. It is used to send and receive the Game and Music data from our entertainment device to an android application.

=== Hardware Design ===

[[File:Slide3.png|700x900px|thumb|center|Bluetooth Interface Pin Diagram]]

===HC-05 Bluetooth module===
HC-05 Bluetooth Module is used to set up wireless communication between the entertainment device and the Android phone. The right section of the Bluetooth Board has connection pins for power and signals as well as a 5V to 3.3V Regulator, LED, and level shifting.

'''HC-05 PinOut'''
* EN: N/A
* VCC: 5V Power
* GND: Ground
* TXD: Serial Transmit pin connected to RXD3 of SJ board
* RXD: Serial Receive pin connected to TXD3 of SJ board
* STATE: States if connected or not

=== Software Design ===

[[File:Bluetooth_Sw_diagram.png|600x500px|thumb|center|Bluetooth Software Design]]

=== Implementation ===

An accelerometer is used in the MP3 Mode to implement functionalities such as play, pause, switch to next and previous songs and volume control. In the game mode the “Fruit fury” game is played by smashing fruits appearing in the directions South East, South West, North East and North West. UART3 is used as communication protocol.The Bluetooth commands that we are using to interact with Mobile app and Device are as follows:

GAMING = 0xA1,
NORTH_EAST = 0x71,
NORTH_WEST = 0x72,
SOUTH_WEST = 0x73,
SOUTH_EAST = 0x74,
MUSIC = 0xA2,
SONG_LIST = 0xA3,
NEXT_SONG = 0xC2,
TOGGLE_SONG = 0xC1,
PREV_SONG = 0xC0,
ACK = 0x00,
NACK = 0xFF,
VOL_INC = 0xB1,
VOL_DEC = 0xB0

=='''Mobile Application'''==

{|
|[[File:Modes.jpeg|230px|thumb|List Of Feature in the APP]]
|[[File:GAME.jpeg|230px|thumb|Game Mode]]
|[[File:Mp3_song.jpeg|230px|thumb|MP3 Mode]]
|[[File:SongList.jpeg|230px|thumb|List Of Songs in SD Card]]
|}

=== Software Design ===

The Android app has been built using the cross platform framework [https://flutter.dev/ Flutter]

The app is composed of 3 parts, '''Game Mode''', '''MP3 Mode''' and '''MP3 Song List'''. On the main screen we first connect to the bluetooth before establishing connection with any of the modes. The working of each mode is explained in each subsection below.

A few variables to note in advance
ACK = 0x00, sent when successful
NACK = 0xFF, sent incase there is any error

====1. Game Mode ====

Wireless communication with the Entertainment box communication over Bluetooth protocol. Android Application is created which provides an interface to exchange data and configure the device.To enter the Game Mode screen we first check if the Bluetooth Connection is established. We send in a one byte data 0xa1 over bluetooth to the SJ2 Board and get back the response "a1$ack/nack$##" We then enter the game mode which displays a joystick that can be oriented to a direction wherever the fruit appears on the LED matrix. The corresponding orientation value is then transmitted.If the fruit had appeared in any of the quadrant then will send data from BLE APP to SJTwo Board.

'''1.''' First Quadrant (North-East): 0x71 
'''2.''' Second Quadrant (North-West): 0x72 
'''3.''' Third Quadrant (South-West): 0x73 
'''4.''' Fourth Quadrant (South-East): 0x74 

====2. MP3 Mode ====

To enter the MP3 Mode screen we first check if the Bluetooth Connection is established similar to the Game Mode. We send in one byte of data 0xa2 over bluetooth to the SJ2 Board and get back the response "a2$ack/nack$volumeInfo$currentSong$isPlaying/isPaused$##" where isPlaying is 1 and isPaused is 0. These values are loaded into the MP3 Mode Screen as initial values for the current song playing. We can then see a screen where we can control the various aspects of playing songs i.e Playing and Pausing the song, Go to next song and and Go to the previous song. We can also control the volume remotely.Controlling each part of this interface is the same as sending a single byte of data over bluetooth to the SJ2 Board.

'''1.''' Playing and Pausing Song - We just toggle the state of the Song. We issue this command by sending 0xc1 which is the Toggle State command. 
'''2.''' Next Song and Previous Song - Command for the previous and next song is 0xC0 and 0xC2. 
'''3.''' Control Volume remotely - For volume we divide the percentage 100 percent in 16 parts. We can send the value between 0xb0 to 0xbf in increments of one step. This is parsed on the SJ2 Board and converted to an equivalent volume signal. 

====3. MP3 Song List ====
To get the list of MP3 Songs which are present in the SD card, we first check if the Bluetooth Connection is established similar to the Game Mode and MP3 Song mode. We send in one byte of data 0xa3 over bluetooth to the SJ2 Board and get back the response "a3$ack/nack$data$data$...$##". APIs that were designed to read song information and data by Audio Decoder, will be used for achieving this functionality.

=='''OLED Screen'''==

=== Software Design ===

The open source package [https://github.com/olikraus/u8g2 u8g2] has been used.
There are already ready made functions for various OLED Drivers. The indepth setup guide can be found [https://github.com/olikraus/u8g2/wiki/u8g2setupc here]

=== Implementation ===

The u8g2 library is a very robust library which means that this code can be extended for any microcontroller as long as the interface is written properly.

We needed to write 2 main functions, outlined below, i.e byte_cb and gpio_and_delay_cb using the function prototype `uint8_t u8x8_lpc_gpio_and_delay(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr)`.

Since the SJ2 Board is connected to the OLED Screen on the SPI1 Bus we also need to write the SPI1 driver, mainly a method to that sends data over SPI to the Slave device i.e the OLED Screen

=== Initializing the u8g2 for LPC4078 ===

<source lang="cpp">

// Created a file `u8g2_wrapper.h

static gpio_s dc;
static u8g2_t u8g2;

void u8g2_wrapper__init(gpio_s *dc_pin) {
u8g2_Setup_ssd1306_128x64_vcomh0_1(&u8g2, U8G2_R0, u8x8_byte_4wire_hw_spi, u8x8_lpc_gpio_and_delay);
u8g2_InitDisplay(&u8g2);
u8g2_SetPowerSave(&u8g2, 0);

dc.pin_number = dc_pin->pin_number;
dc.port_number = dc_pin->port_number;
}

u8g2_t *u8g2_wrapper__get_instance() { return &u8g2; }

uint8_t u8x8_lpc_gpio_and_delay(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr) {
switch (msg) {
case U8X8_MSG_GPIO_AND_DELAY_INIT:
delay__ms(1);
break;
case U8X8_MSG_DELAY_MILLI:
delay__ms(arg_int);
break;
case U8X8_MSG_GPIO_DC:
// DONE, Write to the GPIO_DC Pin
if (arg_int == 0) {
gpio__reset(dc);
} else {
gpio__set(dc);
}
break;
case U8X8_MSG_GPIO_RESET:
break;
}
return 1;
}

uint8_t u8x8_byte_4wire_hw_spi(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr) {
uint8_t *data;
switch (msg) {
case U8X8_MSG_BYTE_SEND:
data = (uint8_t *)arg_ptr;
while (arg_int > 0) {
ussp1__exchange_byte((uint8_t)*data);
data++;
arg_int--;
}
break;
case U8X8_MSG_BYTE_INIT:
break;
case U8X8_MSG_BYTE_SET_DC:
if (arg_int == 0) {
gpio__reset(dc);
} else {
gpio__set(dc);
}
break;
case U8X8_MSG_BYTE_START_TRANSFER:
break;
case U8X8_MSG_BYTE_END_TRANSFER:
break;
default:
return 0;
}
return 1;
}

</source>

=='''Technical Challenges'''==

1. '''RGB LED Matrix''' 

a) Getting control of the matrix was challenging as it needs to follow specific sequence of pin enabling/disabling at appropriate timing.

b) Setting right delays to avoid flickers and get smooth transitioning between frames by using delays or for loops.

c) Fixing high CPU utilization by changing delay__us to vTaskDelay.

d) Designing elements of the game (title screen and fruit objects) which required careful plotting of pixel data.

2. '''Audio Decoder''' 

a) The CPU utilization for sending a song task was very high (80% +).
* In order to reduce the utilization, we gave the vTaskDelay(1) while waiting for the DREQ to be high. The high DREQ indicates that the decoder is ready to receive next 32 bytes of data. So meanwhile, when the DREQ pin is low, we made task to sleep for vTaskDelay(1). After doing this, we significantly reduced the CPU utilization to 15%. We tried with vTaskDelay(2) to get CPU utilization of 10%.
* We further tried to make the CPU utilization below 10%. This was really a tough challenge, and figured out that the actual SPI clock is 1Mhz which is too slow as SPI is meant to operate at much higher speed. We changed the clock rate of SPI to 12MHz but the song speed was too slow. We checked the datasheet of the Mp3 decoder and set the internal clock multiplier to 4.5x. This make the shield operate at high clock rates at 12.XX Mhz. So keeping this in mind we made the SPI speed to 12MHz which is safe. We successfully achieved CPU utilization of 5-6% which is very much in the acceptable range.

=='''Suggestions for Future Students'''==
 '''RGB LED Matrix''' 

* To begin with, focus on writing a simple driver to get control of 1 pixel at a targeted location and then use appropriate loops to light up the entire row/column.

* Make sure all pixels are able to light up with all possible colors to eliminate hardware defects.

* Try with minimum / no delays, print tick counts and then come up with meaningful delay numbers.

* Optimize the code (minimum delays, avoiding repetitive function calls, etc.) to bring down the CPU usage level.

* Use the link in the references to draw desired elements and generate the matrix.

 '''Tips for getting GOOD Grades and to remain in top 3 teams''' 
* Select your teammates wisely, and make sure every one dedicates themself for this project.
* Be an active member of your team and review rubrics for the final DEMO.
* As soon as the professor mentions the project, please start working on the project otherwise, in the end, you have to struggle with finals and you will be left with less time for testing and you have to struggle in demo.

 '''General tips''' 
* Remember the KISS approach when you code. (Keep It Simple and Stupid).
* For this project, one should know the basics in C/ C++, FreeRTOS, and some good debugging skills. Because if you don't have one, you will eventually end up spending more time debugging your problem.
* Always give meaningful names to the variable or the function, so a third person reviewing the code gets an overall idea by just reading the name.

=='''Conclusion'''==
It was a really great working experience for all of us. We were really thrilled from the beginning that we will be working on something that is quite relevant in the industries. We worked as a team of four which helped us all to know the importance of team-work and co-ordination. We learned many great stuff like

* State Design using FreeRTOS
* FreeRTOS APIS when task handles are NULL vs when Initialised.
* Uses of extern and global variables as opposed to encapsulation i.e static inside private 'c' files.
* Learning Optimization through the integration of our peer's individual modules
* Improving CPU utilisation of the main LED and MP3 tasks.
* Workload sharing and cooperation amongst peers.
* Sharing ideas and debugging a common problem together i.e team building.
* We realised that using GPP for long term is not a good idea, there were some breakdown in the wires and our MP3 stopped working. Initially we spent a lot of time debugging hardware and doing soldering. So we started designing the PCB, and when our PCB was done, we spent hardly any time debugging the hardware.
* Git : We learnt all the basic of GIT and it plays an important to role for source code versioning.

There were a lot of problems while doing this project but it was a steep learning curve. In the end we were able to achieve our objective with really good results.

=='''Project Video'''==
https://youtu.be/vVjHCoyWYz4

=='''Project Source Code'''==
* Git Project Link (Individual Modules): [https://gitlab.com/Infinity_Mirror/infinity_mirror-cmpe-244]
* Git Project Link: [https://gitlab.com/ganeshram2493/infi_mirror]

=='''Project Presentation File'''==
* [https://drive.google.com/file/d/1Q_Xvs-a2feQcr-FbPEKbwmlhi35hqNxX/view?usp=sharing Presentation Link]

=='''References'''==
=== Acknowledgement ===

We would like to express our gratitude to Professor Preetpal Kang for generously sharing his time and knowledge with us and guiding us through the completion of this project. We would also like to thank the Prashant Gandhi(ISA) for their valuable advice and constructive feedback.

=== References Used ===

====== Flutter Android GUI ======
* [https://material.io/resources/icons/?style=baseline Material Design Icons]
* [https://flutter.dev/ Building a Dynamic UI with Flutter]
* [https://www.youtube.com/channel/UCwXdFgeE9KYzlDdR7TG9cMw Flutter Youtube Channel]

====== RGB LED Matrix Interfacing and Designing ======
* [https://www.sparkfun.com/products/14718 Datasheet and Hookup guide]
* [https://cdn-learn.adafruit.com/downloads/pdf/32x16-32x32-rgb-led-matrix.pdf?timestamp=1543806512/ Wiring and pin information]
* [https://www.riyas.org/2013/12/online-led-matrix-font-generator-with.html Hex code generator to build LED matrix models]

====== MP3 Decoder and Frequency Analyzer ======
* [https://www.sparkfun.com/datasheets/Components/General/MSGEQ7.pdf Seven Band Graphic Equalizer MSGEQ7 Data Sheet]
* [https://www.kr4.us/SparkFun-MP3-Player-Shield.html?gclid=EAIaIQobChMIov3f7PWc2wIVDtVkCh0-rgStEAYYASABEgIEgPD_BwE SparkFun-MP3-Player-Shield Datasheet]

====== Gesture & Orientation Sensors ======
* [https://cdn.sparkfun.com/assets/learn_tutorials/3/2/1/Avago-APDS-9960-datasheet.pdf Gesture Sensor Data Sheet]
* [https://learn.sparkfun.com/tutorials/mma8452q-accelerometer-breakout-hookup-guide/all Accelerometer Sensor Data]

====== General/Miscellaneous ======
* [http://socialledge.com/sjsu/index.php/FreeRTOS_Tutorial FreeRTOS Tutorial]
* [https://sjsu-dev2.readthedocs.io/en/latest/?badge=latest SJTwo-c Documentation]