Difference between revisions of "F16: Spartan and Furious"

From Embedded Systems Learning Academy
Jump to: navigation, search
(→‎Schedule)
(→‎Design & Implementation)
 
(620 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
== Project Title ==
+
== Spartan And Furious ==
 +
Android Application controlled Self-Driving Car using CAN bus.
 +
 
 +
 
 +
[[File:CMPE243 F16 SNF MAIN WIKI IMAGE.JPG|thumb|center]]
  
 
== Abstract ==
 
== Abstract ==
−
This section should be a couple lines to describe what your project does.
+
Embedded systems are unique, they tend to take real world inputs, such as light, and make meaningful applications of this data. A self driving car is the epitome of an embedded system, it takes all kinds of information through various sensors and try to give results in the form of travelling from point A to point B. In this project, we attempt to create a self driving car with the aim of putting into practice the knowledge gained through the CMPE 243 course.
 +
 
 +
The key features of the self driving car are:
 +
* Android App controlled start/stop and source/destination selection of the vehicle.
 +
* Navigation of the car on the desired path.
 +
* Obstacles avoidance in the path.
 +
* Closed loop feedback to maintain speed uphill or downhill.
 +
<br clear= all>
 +
 
 +
The system consists of six SJOne Boards that run FreeRTOS and communication between the boards is established using the robust and high speed CAN Communication BUS.
 +
 
 +
[[File:CMPE243 F16 SNF System Diagram.png|thumb|centre|700px|System Diagram]]
  
 
== Objectives & Introduction ==
 
== Objectives & Introduction ==
−
Show list of your objectives. This section includes the high level details of your project. You can write about the various sensors or peripherals you used to get your project completed.
+
In this project, we aim to use the CAN bus to create a self-driving car that can travel between two pre-determined points. The path for the car is given through a mobile application based on the android operating system. The car then navigates between these points by taking location feedback through a GPS system and using ultrasonic sensors embedded on the car to avoid obstacles in the path of the car. IO systems present on the car give us pertinent information about the status of the car and the onboard processing.
 +
 
 +
The Objectives for this project are:<br>
 +
* The car must be able to interact with a Bluetooth enable mobile application and provide a path that the car must follow.<br>
 +
* Given the path to follow, the car must use a GPS module to gather location feedback and route the car toward its destination.<br>
 +
* The car must be able to determine obstacles in its path using ultrasonic sensors and avoid.<br>
 +
* The car must be able to control its speed in various terrain using a speed feedback mechanism.<br>
 +
* Provide meaningful information about the car’s present status using IO modules such as LEDs and LCD.<br>
 +
* A master board must be able to determine the correct action required for the data gathered through sensors and GPS feedback.<br>
 +
* All the modules must communicate with each other over the CAN bus.<br>
 +
* Document the findings in this report for future classes to reference so that they may improve this design.<br>
  
 
== Team Members & Responsibilities ==
 
== Team Members & Responsibilities ==
−
*  Android and Communication Bridge:
+
*  Android and Communication Bridge:[[File:SPARTAN_FURIOUS.png|233px|right]]
 
** [http://www.linkedin.com/in/manali-deshmukh-a8a33994 Manali Deshmukh]<br>
 
** [http://www.linkedin.com/in/manali-deshmukh-a8a33994 Manali Deshmukh]<br>
 
*  Geographical Controller:
 
*  Geographical Controller:
Line 23: Line 48:
  
 
== Schedule ==
 
== Schedule ==
 +
Legend:
 +
 +
<font color="blue"> Motor Controller <font>,<font color="clouds"> Master Controller <font>,<font color="green"> Android Controller<font>,<font color="CARROT"> Geo Controller,<font color="orange"> Sensor and I/O Controller <font>, <font color="black"> Team Goal <font>
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
Line 37: Line 65:
 
|  
 
|  
 
* Purchased RC car.
 
* Purchased RC car.
−
| Complete
+
| Complete.
 
|-
 
|-
 
! scope="row"| 2
 
! scope="row"| 2
 
| 9/24/2016
 
| 9/24/2016
 
|
 
|
−
* Individual module distribution
+
* Individual module distribution.
−
* Project report setup
+
* Project report setup.
−
* Git setup
+
* Git setup.
−
* Order components
+
* Order components for individual modules.
 
|  
 
|  
−
* Members identified for modules
+
* Members identified for modules.
−
* Wikipage project report template and Git were setup
+
* Wikipage project report template and Git were setup.
−
* Ordered GPS module and CAN transceivers
+
* Ordered GPS module and CAN transceivers.
 
| Complete
 
| Complete
 
|-
 
|-
Line 55: Line 83:
 
| 10/01/2016
 
| 10/01/2016
 
|
 
|
−
* Define scope of each module
+
* Define scope of each module.
−
* Determine Git flow
+
* Determine Git flow.
−
* Follow up on component procurement
+
* Follow up on component procurement.
 +
*<font color="blue">Determining and analyzing the duty cycle for servomotor and DC motor of the car.</font>
 +
*<font color="clouds">Implement basic CAN communication CAN between two SJ-One Boards.</font>
 
|  
 
|  
−
* Initial flow of each module defined
+
* Initial flow of each module defined.
−
* Identified the branches and decided on merge process
+
* Identified the branches and decided on merge process.
−
* Ordered additional ultrasonic sensors and LCD
+
* Ordered additional ultrasonic sensors and LCD.
 +
*<font color="blue">Tested the car servo and DC motor using Digital Oscilloscope.<br>
 +
* Observed and noted the duty cycle wave forms <font>.
 +
*<font color="clouds">Successfully tested CAN communication between two SJ-One boards.<br><font>
 
| Complete
 
| Complete
 
|-
 
|-
Line 69: Line 102:
 
* Create branches in Git
 
* Create branches in Git
 
* Follow up on component procurement
 
* Follow up on component procurement
 +
*<font color="blue"> Basic testing of Servo and DC motor.<br></font>
 +
*<font color="blue"> Testing speed of car with variable PWM.</font>
 +
*<font color="clouds">Research on the CAN bus, tasks and scheduling.<br></font>
 +
*<font color="clouds">Decision regarding flow of the master controller.</font>
 +
*<font color="orange">Download software for LCD</font>
 
|  
 
|  
 
*Created Master branch on Git
 
*Created Master branch on Git
−
*All ordered parts received on 10/07
+
*All ordered parts received by 10/07.
 +
*<font color="blue">Implemented test code to interface SJOne board with a servo motor to control the direction and verified the same on the car.
 +
* Speed testing in progress.</font>
 +
*<font color="clouds">Learnt about the working of CAN bus and decided on flow for the master controller.</font>
 +
*<font color="orange">Installed 4D System Workshop4 IDE (for LCD).</font>
 +
 
 
| Complete
 
| Complete
 
|-
 
|-
 
! scope="row"| 5
 
! scope="row"| 5
−
| 10/22/2016
+
| 10/15/2016
 
|
 
|
−
*Prepare CAN DBC file. <font color="blue">
+
*<font color="blue"> Developing drivers for both motors.</font>
−
|
+
*<font color="green">Android app prototype.</font>
 +
*<font color="CARROT"> Parse GPS data and format the data to be transmitted.</font>
 +
*<font color="clouds">Decision making regarding various messages to be sent on CAN bus.</font>
 +
*<font color="orange">Design basic sensor algorithm for range finding. </font>
 
|  
 
|  
 +
*<font color="blue">Algorithm developed for both the motors.</font>
 +
*<font color="green"> Basic App Screen layout designed.</font>
 +
*<font color="CARROT">GPS latitude & longitude coordinates extracted from NMEA format.</font>
 +
*<font color="clouds">Identified various messages for different nodes.</font>
 +
*<font color="orange">Designed basic algorithm for range finding. </font>
 +
| Complete
 
|-
 
|-
 
! scope="row"| 6
 
! scope="row"| 6
 +
| 10/22/2016
 +
|
 +
*Define CAN signals for each module.
 +
* <font color="blue"> Testing the car with developed drivers.</font>
 +
*<font color="green">Interface Bluetooth module with SJ-One board.</font>
 +
*<font color="CARROT">Implement source code and fetch Magnetometer reading.</font>
 +
*<font color="clouds">Design of CAN bus hardware.</font>
 +
*<font color="orange">Test basic working for IR.</font>
 +
 +
|
 +
*CAN signals along with their priorities identified (DBC file format generated).
 +
*<font color="blue">Testing for developed motor drivers in progress.</font>
 +
*<font color="green"> Testing of Bluetooth interface in progress.</font>
 +
*<font color="CARROT">Implemented the Magnetometer source code, Testing in progress.</font>
 +
*<font color="clouds">Tested for hardware integrity.</font>
 +
*<font color="orange">Developed algorithm for obstacle detection.</font>
 +
| Complete.
 +
|-
 +
! scope="row"| 7
 
| 10/29/2016
 
| 10/29/2016
 
|
 
|
−
*Designing of CAN hardware.
+
*<font color="blue"> Fine tuning motor control code.</font>
−
*Testing and debugging.
+
*<font color="green">Transmitting and receiving messages between Android App and SJ-One board.</font>
−
|
+
*<font color="CARROT"> Test the extracted GPS data for consistency and check the update rate.</font>
−
|  
+
*<font color="clouds">Basic interfacing of master controller with motor module.</font>
 +
*<font color="orange"> Integrate IR sensor for gauging speed. </font>
 +
 
 +
|
 +
*<font color="blue">Testing in Progress for the motor control code.</font>
 +
*<font color="green"> Successfully established communication interface between app and SJ-one board</font>
 +
*<font color="CARROT">Latitude and Longitude parsed data tested, observed few NMEA strings with wrong checksum values.</font>
 +
*<font color="clouds">Testing in Progress of the interface over CAN bus.</font>
 +
*<font color="orange">Developed algorithm for obstacle detection.</font>
 +
*<font color="orange"> Speed sensing was delegated to motor team as suggested by Preet. </font>
 +
| Complete.
 
|-
 
|-
−
! scope="row"| 7
+
! scope="row"| 8
 
| 11/05/2016
 
| 11/05/2016
 
|
 
|
 
*Integration of modules for first demo.
 
*Integration of modules for first demo.
−
|  
+
| Integration and Testing completed for the first demo.
−
|  
+
| Complete.
 +
|-
 +
! scope="row"| 9
 +
| 11/12/2016
 +
|
 +
*<font color="blue"> Design of Feedback Control mechanism for car.</font>
 +
*<font color="CARROT"> Initial algorithm development of GPS module for heading calculation.</font>
 +
*<font color="clouds">Integration of master module with bluetooth module .</font>
 +
*<font color="orange">Develop LCD code for displaying all sensor information and car vitals. </font>
 +
*<font color="orange">Decide upon additional I/O such as lights. </font>
 +
|
 +
*<font color="blue"> Developed algorithm for motor feedback mechanism. </font>
 +
*<font color="CARROT">Initial algorithm developed for GPS heading calculation and tested.</font>
 +
*<font color="clouds"> Communication between bluetooth and master module established successfully .</font>
 +
*<font color="orange">Created project in Workshop4 IDE for all elements to be displayed by LCD.</font>
 +
*<font color="orange">Found UART commands to control each element in the LCD display.</font>
 +
*<font color="orange">I/O hardware was decided upon.</font>
 +
| Complete.
 
|-
 
|-
−
! scope="row"| 8
+
! scope="row"| 10
 
| 11/19/2016
 
| 11/19/2016
 
|
 
|
−
*Integration of Android app with I/O, sensor and motor feedback.
+
*<font color="blue"> Speed synchronization of car using speed sensor and testing.</font>
−
|
+
*<font color="green">Interfacing Android controller with the GPS module</font>
 +
*<font color="CARROT">Algorithm for distance and heading calculation.</font>
 +
*<font color="CARROT">Coding and Calibration of GPS module.</font>
 +
*<font color="clouds">Interface of master module with I/O module and testing to ensure predicted output.</font>
 +
*<font color="orange">Integrate sensor and I/O code. </font>
 
|  
 
|  
 +
*<font color="blue">Integrated speed sensor for calculating the speed and controlling motor speed. </font>
 +
*<font color="green">Interface of Android controller with the GPS module conducted successfully.</font>
 +
*<font color="CARROT">Algorithm implemented for distance and heading calculation.</font>
 +
*<font color="CARROT">Calibration of Magnetometer ongoing.</font>
 +
*<font color="clouds"> Communication between I/O module and master module established successfully .</font>
 +
*<font color="orange">LCD code completed and sensors adjusted to work in tandem with obstacle avoidance logic. </font>
 +
|Complete
 
|-
 
|-
−
! scope="row"| 8
+
! scope="row"| 11
 
| 11/26/2016
 
| 11/26/2016
 
|
 
|
 
*Testing and debugging for second demo.
 
*Testing and debugging for second demo.
 +
<font color="green"></font>
 
|
 
|
−
|  
+
*Integration and testing complete for second demo.
 +
|Complete
 +
|-
 +
! scope="row"| 12
 +
| 12/03/2016
 +
|
 +
*Fine tuning, debugging and integration.
 +
*<font color="CARROT">Algorithm to be implemented for Direction: Half Left, Left, Right, Half Right and Straight etc</font>
 +
*<font color="CARROT">Initial Testing to be done with default hard-coded GPS checkpoint values</font>
 +
 
 +
|
 +
*Fine tuning on Geo, Android and I/O module algorithm.
 +
*<font color="CARROT">Compass mounted on the car and re-calibration done.</font>
 +
*<font color="CARROT">Algorithm implemented for steer command.</font>
 +
*<font color="CARROT">Testing completed with default hard-coded GPS coordinates</font>
 +
*<font color="CARROT">Calibrated the steer command angle range and the distance offset value while reaching the checkpoint </font>
 +
|Complete
 
|-
 
|-
−
! scope="row"| 8
+
! scope="row"| 13
 
| 12/10/2016
 
| 12/10/2016
 
|
 
|
−
*Final Testing and fine tuning  
+
*Final testing and fine tuning  
 
*Report preparation
 
*Report preparation
−
|  
+
 
−
|  
+
|
 +
*Final testing done.
 +
| Complete
 
|-
 
|-
 
|}
 
|}
  
 
== Parts List & Cost ==
 
== Parts List & Cost ==
−
Give a simple list of the cost of your project broken down by components.  Do not write long stories here.
 
  
−
== ECUs ==
 
−
== Motor Controller ==
 
−
==== Group Members ====
 
−
*'''''[http://www.linkedin.com/in/srinivasanshilpa Shilpa Srinivasan]<br> '''''
 
−
 
−
=== Schedule ===
 
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
−
! scope="col"| Week#
+
! scope="col"| Item#
−
! scope="col"| Date
+
! scope="col"| Part Description
−
! scope="col"| Task
+
! scope="col"| Vendor
−
! scope="col"| Actual
+
! scope="col"| Qty
−
! scope="col"| Status
+
! scope="col"| Cost
 
|-
 
|-
 
! scope="row"| 1
 
! scope="row"| 1
−
| 10/01/2016
+
| [[SJ_One_Board|SJ One Board (LPC 1758)]]
−
|
+
| From Preet
−
* Determining and analyzing the duty cycle for servomotor and DC motor of the car
+
| 6
−
|  
+
| $480
−
* Tested the car servo and DC motor using Digital Oscilloscope.<br>
 
−
* Observed and noted the duty cycle wave forms.
 
−
| Complete
 
 
|-
 
|-
 
! scope="row"| 2
 
! scope="row"| 2
−
| 10/08/2016
+
| [https://traxxas.com/products/models/electric/67054-1stampede4x4 RC Car]
−
|
+
| Sheldon Hobbyist
−
* Basic testing of Servo and DC motor.<br>
+
| 1
−
* Testing speed of car with variable PWM.
+
| $309.99
−
|  
 
−
* Implemented test code to interface SJOne board with a servo motor to control the direction and verified the same on the car.
 
−
* Speed testing in progress.
 
−
| Complete
 
 
|-
 
|-
 
! scope="row"| 3
 
! scope="row"| 3
−
| 10/15/2016
+
| [https://www.adafruit.com/products/1120 Accelerometer/Magnetometer LSM303]
−
|
+
| Adafruit
−
* Developing drivers for both motors.
+
| 2
−
* Testing the car with developed drivers.
+
| $40.00
−
|  
 
−
*
 
−
|
 
 
|-
 
|-
 
! scope="row"| 4
 
! scope="row"| 4
−
| 10/22/2016
+
| [https://www.sparkfun.com/products/12582 Bluetooth Module]
−
|
+
| Sparkfun
−
* Establishing basic CAN communication.<br>
+
| 1
−
* Interfacing with Master Controller with Motor.  
+
| $34.95
−
|
 
−
*
 
−
|
 
 
|-
 
|-
 
! scope="row"| 5
 
! scope="row"| 5
−
| 10/29/2016
+
| [http://www.microchip.com/wwwproducts/en/en010405 CAN Transceivers]
−
|
+
| From Microchip.
−
* Fine tuning motor control code.
+
| 10
−
|  
+
| $0 (Free Samples)
−
*
 
−
|
 
 
|-
 
|-
 
! scope="row"| 6
 
! scope="row"| 6
−
| 11/05/2016
+
| [https://traxxas.com/products/parts/batteries/idpowercellbatteries/nimh/2926X-7C-hump-SubC-3000mAh Battery Pack]
−
|
+
| From Sheldon Hobbist
−
* Testing and debugging.
+
| 1
−
|  
+
| $49.99
−
*
 
−
|
 
 
|-
 
|-
 
! scope="row"| 7
 
! scope="row"| 7
−
| 11/12/2016
+
| [http://www.maxbotix.com/Ultrasonic_Sensors/MB1000.htm Ultra Sonic Sensor]
−
|
+
| From Maxbotix
−
* Design of Feedback Control mechanism for car.
+
| 5
−
|  
+
| $91.15 (at 40% student discount)
−
*
 
−
|
 
 
|-
 
|-
 
! scope="row"| 8
 
! scope="row"| 8
−
| 11/19/2016
+
| [http://www.digikey.com/en/product-highlight/4/4d-systems/ulcd-32ptu-display-module LCD Display]
−
|
+
| From Digikey
−
* Speed synchronization of car using IR sensor and testing.
+
| 1
−
|  
+
| $94.21
−
*
 
−
*
 
−
|
 
 
|-
 
|-
 
! scope="row"| 9
 
! scope="row"| 9
−
| 11/26/2016
+
| [https://www.adafruit.com/products/746 GPS Module]
−
|
+
| From Adafruit
−
* Testing and integration with all modules.
+
| 1
−
|  
+
| $43.34
−
*
 
−
*
 
−
|
 
 
|-
 
|-
 
! scope="row"| 10
 
! scope="row"| 10
−
| 12/03/2016
+
|General Components
−
|
+
| From HSC electronics
−
* Fine tuning, debugging and integration.
+
| -
−
|  
+
| $83.17
−
*
+
|-
−
*
+
! scope="row"| 11
−
|
+
|[https://www.adafruit.com/product/904 DC Current Sensor]
 +
| From Adafruit
 +
| 1
 +
| $14.39
 +
|-
 +
! scope="row"| 12
 +
|PCB
 +
| From Amazon
 +
| 1
 +
| $10.66
 +
|-
 +
! scope="row"| 13
 +
|Corrugated Sheet for chasis
 +
| From Home Depot
 +
| 1
 +
| $6.74
 +
|-
 +
! scope="row"| 14
 +
|[http://www.peak-system.com/PCAN-USB.199.0.html?L=1 PCAN dongle]
 +
| From Preet
 +
| 1
 +
| $0
 +
|-
 +
|}
 +
 
 +
== Car Framework and Components ==
 +
 
 +
Stampede 4X4 is built on the advanced shaft-driven 4WD system and innovative modular design of the Slash 4X4. The chassis fully integrates the electronics and battery compartment for an efficient and compact layout, and maintains the high center ground clearance. It uses just three gear meshes to drive all four wheels, eliminating the need for a multi-gear transmission. The highly efficient drive train spins effortlessly on rubber-sealed ball bearings, and is integrated seamlessly into the unique chassis for optimum performance and easy maintenance. A single center driveshaft connects the front and rear drive assemblies for maximum power transfer. To harness the torque of the Titan 12-turn motor, Traxxas bolted in the high-performance, waterproof XL-5 electronic speed control. EZ-Set one-button setup makes it easy to adjust or change profiles.
 +
 
 +
[[File:CMPE243_F16_SnF_Car_framework.png|thumb|centre|700px|Car Framework]]
 +
 
 +
== CAN BUS Design ==
 +
CAN Communication is used to communicate between all the boards. CAN Protocol requires the bus to be terminated using two 120 Ohm resistors. CAN is a broadcast bus. Based on the .dbc file, each module will transmit only selected messages. Receiving of the messages is enabled by filtering. Module can be configured to receive all messages or receive selected messages.
 +
<br>
 +
 
 +
 
 +
[[ File: CMPE243_F16_SnF_CAN_Interface.jpg|frame|centre|600px|CAN Interface]]
 +
 
 +
 
 +
<br clear= all>
 +
==== CAN 11-bit ID Format ====
 +
We have used 11-bit ID format for all the messages. The message ids have been defined to represent the transmitter, receiver and the message.
 +
 
 +
{| class="wikitable"
 +
|-
 +
! scope="col"| SRC
 +
! scope="col"| DST
 +
! scope="col"| MSG
 +
|-
 +
| 3 bits (10-8)
 +
| 4 bits (7-4)
 +
| 4 bits (3-0)
 +
|-
 +
|}
 +
 
 +
==== Controller ID Table ====
 +
Each module has been assigned a number. This number is used to define the message ids.
 +
 
 +
{| class="wikitable"
 +
|-
 +
! scope="col"| Controller ID
 +
! scope="col"| Controller Type
 +
|-
 +
| 0
 +
| System Command
 +
|-
 +
| 1
 +
| Master Controller
 +
|-
 +
| 2
 +
| Sensor Controller
 +
|-
 +
| 3
 +
| BLE Controller
 +
|-
 +
| 4
 +
| Geo Controller
 +
|-
 +
| 5
 +
| Motor Controller
 +
|-
 +
| 6
 +
| I/O Controller
 +
|}
 +
 
 +
==== CAN Communication Table ====
 +
The table indicates the messages based on the transmitter.
 +
 
 +
{| class="wikitable"
 +
|-
 +
! scope="col"| Sr. No
 +
! scope="col"| Message ID
 +
! scope="col"| Message function
 +
! scope="col"| Receivers
 +
|-
 +
|-
 +
! colspan="4"| System Commands
 +
|-
 +
|-
 +
|1
 +
|10
 +
| System communication command
 +
|Master
 +
|-
 +
|-
 +
|-
 +
! colspan="4"| Master Controller Commands
 +
|-
 +
|-
 +
|2
 +
|100
 +
|Master System Command for the all modules to start or stop processing
 +
|BLE, Geo, I/O, Motor, Sensor
 +
|-
 +
|3
 +
|151
 +
|Steer and Drive command for the Motor module
 +
|Motor, I/O
 +
|-
 +
|4
 +
|162
 +
|Display the active state of each module
 +
|BLE, I/O
 +
|-
 +
|-
 +
|-
 +
! colspan="4"| Sensor Controller Commands
 +
|-
 +
|-
 +
|5
 +
|211
 +
|Obstacle Data
 +
|Master, I/O
 +
|-
 +
|6
 +
|214
 +
|Heartbeat
 +
|Master
 +
|-
 +
|7
 +
|263
 +
|Battery Health
 +
|I/O
 +
|-
 +
|-
 +
|-
 +
! colspan="4"| BLE Controller Commands
 +
|-
 +
|-
 +
|8
 +
|314
 +
|Heartbeat
 +
|Master
 +
|-
 +
|9
 +
|341
 +
|Checkpoints
 +
|Geo
 +
|-
 +
|-
 +
|-
 +
! colspan="4"| Geo Controller Commands
 +
|-
 +
|-
 +
|10
 +
|411
 +
|Calculated Direction for the car
 +
|Master
 +
|-
 +
|11
 +
|413
 +
|Destination Reached flag
 +
|Master, BLE, I/O
 +
|-
 +
|12
 +
|414
 +
|Heartbeat
 +
|Master
 +
|-
 +
|13
 +
|431
 +
|Start point
 +
|BLE, I/O
 +
|-
 +
|14
 +
|461
 +
|Compass data
 +
|I/O
 +
|-
 +
|-
 +
|-
 +
! colspan="4"| Motor Controller Commands
 +
|-
 +
|-
 +
|15
 +
|514
 +
|Heartbeat
 +
|Master
 +
|-
 +
|16
 +
|561
 +
|Car speed
 +
|I/O
 +
|-
 +
|-
 +
|-
 +
! colspan="4"| I/O Controller Commands
 +
|-
 +
|-
 +
|17
 +
|614
 +
|Heartbeat
 +
|Master
 
|-
 
|-
 
|}
 
|}
 +
 +
==== DBC File ====
 +
DBC file is designed based on the designed CAN messages and signals. Preet's python script is used to auto generate CAN communication related structures and functions. Each module will generate its specific generated_can.h by changing the module name in 'pre_build.sh' file.
 +
The following is the example of generating the auto code for master module.
 +
 +
 +
                  python ../_can_dbc/dbc_parse.py -i ../../snf.dbc -s MASTER > ../_can_dbc/generated_can.h
 +
 +
 +
 +
The DBC file can be found at the following link:
 +
*[https://gitlab.com/ankitas/spartan_and_furious/blob/master/snf.dbc Git DBC File Link]
 +
 +
==== Can Bus analyzer ====
 +
 +
The PCAN-USB adapter enables simple connection to CAN networks. Bus Master software and PCAN-View software has been used to read and debug CAN messages.
 +
Bus Master requires DBC file to be converted to .dbf file. The messages can be viewed in very detailed format in the Bus Master. Both the tools along with PCAN dongle are very useful in debugging the CAN communication. It is also possible to record the logs of the communication.
 +
 +
[[ File: CMPE243_F16_SnF_CAN_dongle.png|thumb|center|700px|PCAN Dongle]] <br>
 +
 +
[[ File: CMPE243 F16 SnF PCAN View.JPG|thumb|center|1000px|Snapshot of the CAN messages on the PCAN-VIEW tool]]<br>
 +
 +
[[ File: CMPE243 F16 SnF BusMaster.JPG|thumb|center|1000px|Snapshot of the CAN messages on the Bus Master tool]]
 +
 +
== ECUs ==
 +
 +
== Android and Communication Bridge ==
 +
==== Group Members ====
 +
*'''''[http://www.linkedin.com/in/manali-deshmukh-a8a33994 Manali Deshmukh]<br> '''''
  
 
=== Design & Implementation ===
 
=== Design & Implementation ===
−
The design section can go over your hardware and software design.  Organize this section using sub-sections that go over your design and implementation.
+
The Android and communication bridge controller is responsible for establishing communication between the car and the Android app using BlueSMiRF RN41 bluetooth module.  The Android app sends the check points to the car helping it to make its way to the destination and also receives the data from various modules to be displayed on the app. The data is transferred and recieved from other controllers via CAN bus. The bluetooth module communicates with the SJOne board using UART communication at 115200 bps.  The SJOne and bluetooth module connections are as follows: <br>
 +
 
 +
[[File:CMPE_243_F16_SnF_BLE_Block_Diagram.gif|thumb|centre|1200px|BLE Block Diagram]]
 +
 
 +
=====Pin Configuration: =====
 +
{| class="wikitable"
 +
|-
 +
! scope="col"| Sl. No
 +
! scope="col"| Pin on SJOne Board
 +
! scope="col"| Pin on BlueSMiRF RN41 Bluetooth module
 +
! scope="col"| Purpose
 +
|-
 +
|-
 +
|1
 +
|TXD2
 +
|RXD
 +
|Transmit using UART2(TXD2) to RN41
 +
|-
 +
|-
 +
|2
 +
|RXD2
 +
|TXD
 +
|Receive using UART2(RXD2) from RN41
 +
|-
 +
|-
 +
|3
 +
|3V3
 +
|VCC
 +
|3.3V voltage supply
 +
|-
 +
|-
 +
|4
 +
|GND
 +
|GND
 +
|Ground
 +
|}
  
 
=== Hardware Design ===
 
=== Hardware Design ===
−
Discuss your hardware design here.  Show detailed schematics, and the interface here.
 
  
−
=== Hardware Interface ===
+
[[File:CMPE243 F16 SnF Bluetooth Modem.jpg|thumb|right|250px|Bluetooth Modem]]
−
In this section, you can describe how your hardware communicates, such as which BUSes used. You can discuss your driver implementation here, such that the '''Software Design''' section is isolated to talk about high level workings rather than inner working of your project.
+
 
 +
Bluetooth Module BleSMiRF Gold
 +
Features:
 +
*v6.15 Firmware
 +
*FCC Approved Class 1 Bluetooth****Radio Modem
 +
*Extremely small radio - 0.15x0.6x1.9"
 +
*Very robust link both in integrity and transmission distance (100m) - no more buffer overruns!
 +
*Low power consumption : 25mA avg
 +
*Hardy frequency hopping scheme - operates in harsh RF environments like WiFi, 802.11g, and Zigbee
 +
*Encrypted connection
 +
*Frequency: 2.402~2.480 GHz
 +
*Operating Voltage: 3.3V-6V
 +
*Serial communications: 2400-115200bps
 +
*Operating Temperature: -40 ~ +70C
 +
*Built-in antenna
 +
 
 +
=== Software Design and Implementation===
 +
 
 +
The Software design for the app is as follows:
 +
 
 +
1. The current location of the car is extracted through the GPS of the mobile.
 +
 
 +
2. As per location, a route is calculated by the app and checkpoints is sent to the BLE module(SJ-one board)
 +
 
 +
3. The Decoding of the received messages is implemented in 10Hz task.
 +
 
 +
4. Due to challenges faced to parse data in 10Hz, decision was made to shift parsing of data to 1Hz task.
 +
 
 +
5. After parsing the data, the checkpoints are then send over the CAN bus to Geo module for processing.
 +
 +
[[File:CMPE243 F16 SnF BLE Software Implement.png|thumb|left|500px|BLE Module Software Implementation]]
 +
<br clear=all>
 +
 
 +
===== Android App =====
 +
 
 +
A bluetooth connection is established between android app and bluetooth module. The android app sends a start bit on UART to the master controller to indicate the start of the app and it acts as the start button for the car. The app starts listening to the incoming data and fetches the current location of the car. The distance is calculated between the start and destination location. The JSON is generated from the google map API from where we fetch the check points to be sent to the geo controller. The app also displays the relevant car information for the user.
 +
 
 +
[[File:CMPE 243 F16 SnF BLE Flowchart.jpg|thumb|center|700px|Android App Flow Chart]]<br>
 +
[[File:CMPE243_F16_SnF_AppScreen1.jpeg|thumb|left|200px|App Screen 1]]
 +
[[File:CMPE243_F16_SnF_AppScreen2.jpeg|thumb|center|200px|App Screen 2]]
 +
 
 +
[[File:CMPE243_F16_SnF_AppScreen3.jpeg|thumb|left|200px|App Screen 3]]
 +
[[File:CMPE243_F16_SnF_AppScreen4.jpeg|thumb|center|200px|App Screen 4]]
 +
 
 +
<br clear=all>
 +
 
 +
===== BLE Controller =====
 +
 
 +
The BLE controller initially enables the uart2 and CAN bus to establish communication between the app and other modules on the CAN bus. The car starts with the command from the app which is received in the 10Hz task and is sent to master module to notify other modules on the CAN bus. After generating route on the app, the app sends the check points to the BLE controller which parses the latitude and longitude values and sends it to the Geo module through the CAN bus.
 +
 
 +
[[File:CMPE243 F16 SnF BLE.jpg|thumb|left|700px|Communication Bridge Flow Chart]]
 +
<br clear=all>
 +
 
 +
=== Testing & Technical Challenges ===
 +
While receiving data from android app, it was observed that there was loss of information due to the buffer size and the receive queue size. It was solved by increasing the buffer and queue size and also due to baudrate, decision was made to receive data in 10Hz and use the same in 1 Hz task. Thus, by adjusting the transfer rates the data loss was reduced.
 +
 
 +
In the android application, bluetooth connectivity was limited to the main activity only and it was difficult to pass it to multiple activities. Therefore, the app was built on only one main activity by processing the data in the background to avoiding crashing. This was done because there are chances of crashing since the UI cannot handle too much on processing.
 +
 
 +
Due to data loss on the app side, it was decided to take the current location from the app and generate the check points. Therefore, to reduce data loss the data was transmitted and received in a thread.
 +
 
 +
==Geographical Controller==
 +
==== Group Members ====
 +
*'''''[http://linkedin.com/in/sreeharshagorantla Harsha Gorantla]<br> '''''
 +
*'''''[http://www.linkedin.com/in/shauryajai Shaurya Jain]<br> '''''
 +
 
 +
=== Design & Implementation ===
 +
 
 +
Geographical Controller is responsible for commanding the Motor Controller on which direction the vehicle has to move. It consists of a Global Positional System (GPS) module to track the current location of the vehicle and a Compass (Magnetometer) to command the direction of steer to the motor with respect to its current direction and Bearing Angle of the GPS.
 +
 
 +
[[ File: CmpE243_Spartan_And_Furious_Block_Diagram.jpg|800px|thumb|center|| Basic Geo Block Diagram]]
 +
 
 +
We have developed the algorithm based on the following parameters:
 +
 
 +
1. Bearing Angle
 +
 
 +
2. Heading Angle
 +
 
 +
'''1. Bearing Angle''': Bearing Angle is the Angle between two points with respect to the Geographical North. We can calculate this from the GPS module by using Haversine formula. Further details are discussed in the Software Design section.
 +
 
 +
[[ File: CmpE243_Spartan_And_Furious_Geo_Bearing_Angle.jpg|600px|thumb|center|| Bearing Angle]]
 +
 
 +
As we can see in the picture, If we consider point A is the current location and point B as the destination, 𝚹 represents the Bearing angle between point A and point B with respect to its Geographical North.
 +
 
 +
'''2.Heading Angle:''' Heading Angle is the angle of the orientation of the vehicle(clockwise) with respect to the Geographical North. The output from the Compass (LSM303) will be from 0 to 360 degrees. However, due to the magnetic declination, the compass needs to be calibrated.
 +
 
 +
[[ File: CmpE243_Spartan_And_Furious_Geo_Compass_Heading.jpg|600px|thumb|center|| Compass Heading]]
 +
 
 +
 
 +
=== Hardware Design ===
 +
 
 +
The below picture shows the hardware schematic of Geo-Controller.
 +
 
 +
[[ File: CmpE243_Spartan_And_Furious_Geo_Hardware_Schematic.jpg|600px|thumb|center|| Hardware Schematic]]
 +
 
 +
'''LSM303DLHC:'''
 +
 
 +
LSM303 has both Compass (Magnetometer) and Accelerometer. We have used LSM303 to calculate the compass raw Heading angle. The LSM303 can be used as a compass by calculating the angle of magnetic field with respect to x-axis and y-axis. The communication between SJOne board and LSM303 is done using the I2C serial bus interface. The connections between LSM303 and SJOne board is showed in the following picture.
 +
 
 +
[[ File: CmpE243_Spartan_And_Furious_Geo_LSM303.jpg|600px|thumb|center|| LSM303]]
 +
 
 +
We used continuous conversion operation mode and the I2C interface supports fast mode which is 400KHz. However, we are using the standard mode which is 100 KHz.
 +
 
 +
[[ File: CmpE243_Spartan_And_Furious_Geo_Compass_pinconnect.png|500px|thumb|center|| Compass-SJOne board Pin Connect]]
 +
 
 +
'''GPS Module:'''
 +
 
 +
The GPS module is very critical to the project as it should be very accurate and fast enough to update the location when the vehicle is moving. So, we have used the Ultimate GPS module from Adafruit which updated at a rate of 10Hz that means the GPS updates the geolocation data every 100 milliseconds. The below picture shows the GPS module. The communication between GPS and SJOne board is done via UART.
 +
 +
The default baud rate of GPS module is 9600. However, we can increase the baud rate based on our requirement.
 +
 
 +
[[ File: CmpE243_Spartan_And_Furious_Geo_Adafruit_Ultimate_GPS.jpg|600px|thumb|center|| Adafruit Ultimate GPS Module]]
 +
 
 +
The pin connect of GPS to SJOne is showed in following picture.
 +
 
 +
[[ File: CmpE243_Spartan_And_Furious_Geo_GPS_pinconnect.png|500px|thumb|center|| GPS-SJOne Pin Connect]]
 +
 
 +
After making proper connections, the GPS will take some time to get the Fix. If the red LED is blinking, we have to understand that the Fix is not available. Sometimes we will not get a fix or it will take more time to get the fix if the board is indoors. From our observations, using a coin battery reduce the fix time in case there is a flakey power connection.
 +
 
 +
[[ File: CmpE243_Spartan_And_Furious_Geo_No_Fix.jpg|600px|thumb|center|| GPS showing No Fix]]
 +
 
 +
The output of GPS module will be strings which consists of multiple data formats such as GPGGA, GPGLL, GPRMC, GPGSA etc. In our software, we have parsed the data only for GPGGA raw data as this string contains all the data required to locate the current location. GPGGA refers to Global Positioning System Fix Data.
 +
The following snapshot gives the complete description of the GPGGA message format.
 +
 
 +
[[ File: CmpE243_Spartan_And_Furious_Geo_GPGGA_Format.jpg|600px|thumb|center|| GPGGA Format]]
  
 
=== Software Design ===
 
=== Software Design ===
−
Show your software design. For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code. For example, do not show exact code, but you may show psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.
+
 
 +
[[ File: CmpE243_Spartan_And_Furious_Geo_System_Flowchart.jpg|1200px|thumb|center|| Geo-Controller Flowchart]]
 +
 
 +
'''Flow of Geo Algorithm:'''
 +
 
 +
1. Receive System start command from master
 +
 
 +
2. Check for GPS Fix.
 +
 
 +
3. If Fix available, send current vehicle geographical coordinates(Latitude and Longitude) to Android via Bluetooth.
 +
 
 +
4. Android receives the current vehicle location, identifies vehicle destination point along with the checkpoints and sends the checkpoints to Geo Controller via CAN.
 +
 
 +
5.    When fix is available and last checkpoint received from Android, Geo-Controller puts all the received checkpoints into a vector one after the other.
 +
 
 +
6.     Geo-Controller checks whether the destination point is reached. If not, Geo-Controller takes one checkpoint at a time and calculates the compass heading, GPS bearing angle and distance from the starting point to first checkpoint (using Haversine formula).
 +
 
 +
7.    After calculating the heading, bearing angles, Geo-Controller decides on which direction the vehicle should move by using the steering control algorithm and gives the direction command to master.
 +
 
 +
8.     Master controls the motor to move in that direction. Once the vehicle reaches the first checkpoint, the same flow continues for the remaining checkpoints.
 +
 
 +
9.    As soon as the last destination checkpoint is popped, we check for the checkpoint vector size. If the vector size is zero and when the vehicle reaches the destination point, we turn a destination reached flag and commands the master to stop the vehicle.
 +
 
 +
We can calculate the bearing angle and distance between the source and destination points using the below mentioned Haversine Formulae.
 +
 
 +
'''Haversine Formula:'''
 +
 
 +
                  a = sin²(Δφ /2) + (cos φ1 ⋅ cos φ2 ⋅ sin²(Δλ/2))
 +
 
 +
                  c = 2 x atan2( √a, √(1−a) )
 +
 
 +
                  Distance, d = R x c
 +
 
 +
                  Where,
 +
 
 +
                                Φ is latitude
 +
 
 +
                                λ is longitude
 +
 
 +
                                R is Earth’s radius i.e., 20,902,231 Feet/6371 Km
 +
 
 +
                                Δφ = latitude2 – latitude1
 +
 
 +
                                Δλ = longitude2 – longitude1
  
 
=== Implementation ===
 
=== Implementation ===
−
This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash.  You can include sub-sections for each of your component implementation.
+
 
 +
 
 +
'''1. Usage of Vectors:''' We used vectors to store and process the checkpoints from Android application. The main reason for using vectors is that the size will grow and shrink with every addition and deletion of checkpoints. So, we can simply check the number of checkpoints left from the vector. We also turned a flag when the vector is empty which means when the flag is on, we have reached the destination.
 +
 
 +
'''2. Steer Command:''' Direction command to master is given based on the different ranges mentioned in the below picture:
 +
 
 +
 
 +
Deflection = Compass Heading - Bearing Angle
 +
 
 +
[[ File: CmpE243_Spartan_And_Furious_Geo_Steer_Command_Range.jpg|600px|thumb|center|| Steer Command Range]]
 +
 
 +
Ex: Consider the vehicle is at 90 degrees (Compass heading) with respect to North, and if the angle between the source and destination is 20 degrees with respect to North(Bearing Angle), which direction the vehicle should turn?
 +
 
 +
A. We know Compass Heading = 90 deg, Bearing Angle = 20 deg. So, the difference is 90 - 20 = 70 deg. deflection, so the vehicle has to turn RIGHT since as per our algorithm, the vehicle has to turn right for 60-180 deg. deflection range(deflection = compass heading - bearing angle).
 +
 
 +
The offset value and the steer angular range is calibrated after rigorous testing. For example: If the compass heading at 60 degree angle from bearing angle (clockwise), we have checked which direction the vehicle is attaining the optimum smooth movement, Half Left or Left? Based on these factors, the calibration is done for steer range.
 +
 
 +
'''3. Dummy Coordinates:''' We are using the dummy coordinates at the start point and at the end point as delimiters. For example, we are sending (1,1) point initially to check for the first checkpoint. Similarly, we are sending (0,0) at the end after receiving the destination point. We implemented an algorithm to check these conditions and send corresponding commands to the master to inform that the vehicle has reached the destination.
  
 
=== Testing & Technical Challenges ===
 
=== Testing & Technical Challenges ===
−
Describe the challenges of your project.  What advise would you give yourself or someone else if your project can be started from scratch again?
 
−
Make a smooth transition to testing section and described what it took to test your project.
 
  
−
== Android and Communication Bridge ==
+
'''Magnetometer Calibration:'''
 +
 
 +
Reason for calibration:
 +
 
 +
As mentioned in the below picture, the LSM303 compass range is not concentric with actual compass range. There will be a deflection due to this. For example; we have observed the deflection of LSM303 compass is very minimal with respect to ideal compass readings for a range of 90 – 180 degrees. However, the LSM303 deflection increases as the LSM303 compass angle deflection will slowly increases from 180 to 360 and 0 to 90 degrees.
 +
 
 +
[[ File: CmpE243_Spartan_And_Furious_Geo_Reason_For_Calibration.jpg|600px|thumb|center|| Reason For Calibration]]
 +
 
 +
Few observations are mentioned in table below. So, we used linear equations to calibrate by finding the slope and the addition factors. Since, the deflection is not linear, we have divided the range of 0-360 angle in three different ranges and applied the linear equations respectively.
 +
 
 +
[[ File: CmpE243_Spartan_And_Furious_Geo_Observed_Magnetometer_Deflection.jpg|600px|thumb|center|| Observed Magnetometer Deflection]]
 +
 
 +
'''Calibration Before Mounting on the Car:'''
 +
 
 +
[[ File: CmpE243_Spartan_And_Furious_Geo_Compass_Calibration_Before_Mounting_on_Car.jpg|600px|thumb|center|| Compass Calibration Before Mounting On Car]]
 +
 
 +
[[ File: CmpE243_Spartan_And_Furious_Geo_Compass_Calibration_Before_Mounting_On_Car_ActualVsObserved.jpg|600px|thumb|center|| Compass Calibration Before Mounting On Car - Actual Vs Observed]]
 +
 
 +
 
 +
However, after mounting the LSM303 compass on the vehicle, the LSM303 compass range from 130 – 220 degrees instead of 90 - 180. So, we have divided the angle into three different ranges i.e., 0 – 185, 185 – 340 and 340 – 360 and applied linear equations as showed below.
 +
 
 +
 
 +
 
 +
                  Y = a X + b;
 +
                 
 +
                  Where,
 +
 
 +
                                Y is actual reading
 +
 
 +
                                X is raw magnetometer readings
 +
 
 +
                                a is multiplication factor
 +
 
 +
                                b is additional factor
 +
 
 +
 
 +
'''Calibration After Mounting on the Car:'''
 +
 
 +
[[ File: CmpE243_Spartan_And_Furious_Geo_Compass_Calibration_After_Mounting_On_Car.jpg|600px|thumb|center|| Compass Calibration After Mounting On Car]]
 +
 
 +
[[ File: CmpE243_Spartan_And_Furious_Geo_Compass_Calibration_After_Mounting_On_Car_ActualVsObserved.jpg|600px|thumb|center|| Compass Calibration After Mounting On Car - Actual Vs Observed]]
 +
 
 +
==Sensor and I/O ==
 
==== Group Members ====
 
==== Group Members ====
−
*'''''[http://www.linkedin.com/in/manali-deshmukh-a8a33994 Manali Deshmukh]<br> '''''
+
*'''''[http://www.linkedin.com/in/bhushanmuthiyan Bhushan Muthiyan]<br> '''''
 +
*'''''[http://www.linkedin.com/in/kparameswaran Karthik Parameswaran]<br>'''''
 +
===SENSOR===
 +
 
 +
----
 +
 
 +
==== Design & Implementation ====
 +
We are using Maxbotix LV-EZ Ultrasonic sensors (MB1000). The configuration of the sensor is 3:1 that is three sensors in the front separated by 60 degrees apart and one in the rear. The ultrasonic sensors mounted on the car are used to detect the obstacle on its route. These sensors are connected to the SJOne board and work with a 5.0V power supply. The SJ One board then sends the sensors message with the help of CAN bus. 
 +
 
 +
The pin description of Maxbotix LV-EZ Ultrasonic sensors is as follows:
 +
 
 +
Pin 1-BW- Unused, leave disconnected or connect to circuit common ground.
 +
 
 +
Pin 2-PW- Digital Proximity Logic, outputs a High/Low logic voltage level depending on proximity detection. High means an object has been detected in the
 +
detection zone. Low means no object is present. There is a ~2.5 second delay on acquiring targets and a ~1.5 second delay for releasing a target once detected. This hysteresis improves sensor reliability.
 +
 
 +
Pin 3-AN- Unused, leave disconnected or connect to circuit common ground.
 +
 
 +
Pin 4-RX- This pin is internally pulled high. The LV-ProxSonar-EZ will continually measure proximity information and output send to data. Leave the pin disconnected or hold the pin high for proximity information. Hold low to stop all sensor activity and reset acquire timers. Upon returning to a high state, the sensor will initiate a calibration sequence.
 +
 
 +
Pin 5-TX- The TX output delivers asynchronous serial with an RS232 format, except voltages are 0-Vcc
 +
 
 +
Pin 6-+5V- Vcc – Operates on 2.5V - 5.5V. Recommended current capability of 3mA for 5V, and 2mA for 3V.
 +
 
 +
Pin 7-GND- Return for the DC power supply. GND (& Vcc) must be ripple and noise free for best operation.
  
−
=== Schedule ===
+
==== Hardware Design ====
 +
The ultrasonic sensor is interfaced through GPIO, each sensor requires 2 pins, PW and RX, in addition to the two pins required for powering up the sensor. The PW pins for each sensor is configured as an interrupt.
 +
The following table and figure shows the pin connections for all the sensors to the SJOne board.
 +
[[File:SNF_Sensor_schematic.png|400px|Sensor Schematic|frame|center]]
 +
<br clear=all>
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
−
! scope="col"| Week#
+
! scope="col"| Sr.No
−
! scope="col"| Date
+
! scope="col"| SJOne Pin Number
−
! scope="col"| Task
+
! scope="col"| Sensor Pin Function
−
! scope="col"| Actual
+
 
−
! scope="col"| Status
 
 
|-
 
|-
 
! scope="row"| 1
 
! scope="row"| 1
−
| 10/01/2016
+
| P1.23
−
|
+
| Middle Sensor PW
−
* Order components
+
 
−
|  
 
−
* Refer previous projects on Wiki to check for components.
 
−
| Complete
 
 
|-
 
|-
 
! scope="row"| 2
 
! scope="row"| 2
−
| 10/08/2016
+
|P 2.3
−
|
+
| Middle Sensor Rx
−
* Follow-up on ordered parts.
+
 
−
|  
 
−
* Components acquired from Preet.<br>
 
−
* Studied the datasheet to understand communication protocol.
 
−
| Complete
 
 
|-
 
|-
 
! scope="row"| 3
 
! scope="row"| 3
−
| 10/15/2016
+
| P 1.28
−
|
+
| Left Sensor PW
−
* Android app prototype
+
 
−
|
 
−
* Established Bluetooth communication with Android App
 
−
| Complete
 
 
|-
 
|-
 
! scope="row"| 4
 
! scope="row"| 4
−
| 10/22/2016
+
| P 2.5
−
|
+
| Left Sensor Rx
−
* Interface Bluetooth module with SJ-One board.<br>
 
−
|
 
−
*
 
−
|
 
 
|-
 
|-
 
! scope="row"| 5
 
! scope="row"| 5
−
| 10/29/2016
+
| P1.22
−
|
+
| Right Sensor PW
−
* Transmitting and receiving messages between Android App and SJ-One board.
+
 
−
|  
 
−
*
 
−
|
 
 
|-
 
|-
 
! scope="row"| 6
 
! scope="row"| 6
−
| 11/05/2016
+
| P 1.29
−
|
+
| Rear Sensor Pw
−
* Testing and debugging.
+
 
−
|  
 
−
*
 
−
|
 
 
|-
 
|-
 
! scope="row"| 7
 
! scope="row"| 7
−
| 11/12/2016
+
| P 2.7
−
|
+
| Rear Sensor Rx
−
* Establishing CAN communication with peripheral modules.
 
−
|
 
−
*
 
−
|
 
−
|-
 
−
! scope="row"| 8
 
−
| 11/19/2016
 
−
|
 
−
* Enhancing UI of the Android App.
 
−
|
 
−
*
 
−
*
 
−
|
 
−
|-
 
−
! scope="row"| 9
 
−
| 11/26/2016
 
−
|
 
−
* Interfacing with GPS module and testing.
 
−
|  
 
−
*
 
−
*
 
−
|
 
−
|-
 
−
! scope="row"| 10
 
−
| 12/03/2016
 
−
|
 
−
* Final integration, testing and debugging.
 
−
|
 
−
*
 
−
*
 
−
|
 
 
|-
 
|-
 
|}
 
|}
  
−
=== Design & Implementation ===
 
−
The design section can go over your hardware and software design.  Organize this section using sub-sections that go over your design and implementation.
 
  
−
=== Hardware Design ===
+
The figure below shows the design for the 3D mount for the front sensors.
−
Discuss your hardware design here. Show detailed schematics, and the interface here.
+
<gallery mpde= "packed" widths=500px>
 +
File:SNF_Ultrasonic_Mount.png|Ultrasonic mount Design
 +
File:CMPE_243_F16_SNF_Usltrasonic_sensor mount.png|3D design
 +
</gallery>
 +
<br clear=all>
 +
 
 +
====Ultrasonic Sensor====
 +
 
 +
There are three ultrasonic sensors for the front of the car positioned at different angles to provide a wide ultrasonic "vision" for the car. The mount for the sensors was 3D printed such that we have the flexibility to change the angle of the sensor at a later stage when debugging the sensor.
  
 
=== Hardware Interface ===
 
=== Hardware Interface ===
 +
 
In this section, you can describe how your hardware communicates, such as which BUSes used.  You can discuss your driver implementation here, such that the '''Software Design''' section is isolated to talk about high level workings rather than inner working of your project.
 
In this section, you can describe how your hardware communicates, such as which BUSes used.  You can discuss your driver implementation here, such that the '''Software Design''' section is isolated to talk about high level workings rather than inner working of your project.
  
−
=== Software Design ===
+
=== Software Design and Implementation ===
−
Show your software design. For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code. For example, do not show exact code, but you may show psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.
+
The readings from the sensor is taken in the form of PWM signals with the help of interrupts.
 +
The following steps were performed to take readings and calculating distance from the sensor
 +
 
 +
# Configure the PW pin of sensor as input.
 +
# Configure RX pin of the sensor as output and set it high.
 +
# Enable the Rising and the Falling edge interrupt on the PW pin of the sensor.
 +
# Start timer at the rising edge of the interrupt (time T1).  
 +
# At falling Edge of the interrupt stop the timer (time T2).
 +
# The distance of the obstacle is = (T2-T1)/147 inches.
 +
#Check for threshold distance. If distance > threshold distance for given sensor, then convey to master that obstacle was found.
 +
#If middle sensor value has distance <= critical distance then convey then set critical bit, conveying that car must stop to avoid a collision
 +
#Broadcast data on CAN bus. <br>
 +
 
 +
 
 +
[[File:CMPE_243_F16_SNF_Sensor_Flowchart.png|thumb|1000px|centre|Sensor Flowchart]]
  
−
=== Implementation ===
+
===I/O===
−
This section includes implementation, but again, not the details, just the high level.  For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash.  You can include sub-sections for each of your component implementation.
 
  
−
=== Testing & Technical Challenges ===
+
----
−
Describe the challenges of your project.  What advise would you give yourself or someone else if your project can be started from scratch again?
+
==== Design & Implementation ====
−
Make a smooth transition to testing section and described what it took to test your project.
+
The IO section for the car consists of two main components, an LCD screen and LED indicators.
  
−
==Geographical Controller==
+
[[File:CMPE_243_F16_SNF_IO.png|thumb|left|500px|LCD Schematic]] [[File:CMPE_243_F16_SNF_IO_LED_Connections.png|thumb|right|500px|frame|LED Schematic]] <br>
−
==== Group Members ====
+
<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>
−
*'''''[http://linkedin.com/in/sreeharshagorantla Harsha Gorantla]<br> '''''
+
IO is integral to troubleshooting the working of the car. The team first decided upon the various important indicators that would be needed to troubleshoot  the working of the car and then decided to translate them into either LED indicators or LCD screen elements. The table below summarizes the features for IO and which IO element was used to represent them on the car.
−
*'''''[http://www.linkedin.com/in/shauryajai Shaurya Jain]<br> '''''
 
  
−
=== Schedule ===
 
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
−
! scope="col"| Week#
+
! scope="col"| Sr.No
−
! scope="col"| Date
+
! scope="col"|Sensor Pin Function
−
! scope="col"| Task
+
! scope="col"| LCD Element
−
! scope="col"| Actual
+
! scope="col"| LED Element Present
−
! scope="col"| Status
+
 
 
|-
 
|-
 
! scope="row"| 1
 
! scope="row"| 1
−
| 10/01/2016
+
| System Command (Start, Stop Resume)
−
|
+
| An on screen LED that turns off/on for each command
−
* Order components
+
|Yes
−
|  
+
 
−
* Refer previous projects wiki to check for components.<br>
 
−
* Ordered GPS module and Magnetometer
 
−
| Complete
 
 
|-
 
|-
 
! scope="row"| 2
 
! scope="row"| 2
−
| 10/08/2016
+
|Right Turn
−
|
+
|An on screen LED that turns off/on
−
* Follow up on ordered parts
+
| Yes
−
|  
+
 
−
* Parts received on 3rd Oct.
 
−
* Go through Adafruit GPS datasheet to understand the supported formats
 
−
| Complete
 
 
|-
 
|-
 
! scope="row"| 3
 
! scope="row"| 3
−
| 10/15/2016
+
| Left Turn
−
|
+
| An on screen LED that turns off/on
−
* Parse GPS data and format the data to be transmitted
+
|Yes
−
* Test code to get compass reading information
+
 
−
|  
 
−
*
 
−
|
 
 
|-
 
|-
 
! scope="row"| 4
 
! scope="row"| 4
−
| 10/22/2016
+
| Brake
−
|
+
| An on screen LED that turns off/on
−
* Interfacing GPS and compass to SJOne board
+
|Yes
−
|
 
−
*
 
−
|
 
 
|-
 
|-
 
! scope="row"| 5
 
! scope="row"| 5
−
| 10/29/2016
+
| Forward
−
|
+
| An on screen LED that turns off/on
−
* Initial Algorithm development of GPS module for distance calculation
+
|Yes
−
* Establishing basic CAN communication
+
 
−
|  
 
−
*
 
−
|
 
 
|-
 
|-
 
! scope="row"| 6
 
! scope="row"| 6
−
| 11/05/2016
+
| Reverse
−
|
+
| An on screen LED that turns off/on
−
* Collaborating with other modules for first demo
+
|Yes
−
|  
+
 
−
*
 
−
|
 
 
|-
 
|-
 
! scope="row"| 7
 
! scope="row"| 7
−
| 11/12/2016
+
| Right Sensor
−
|
+
| Gauge
−
* Algorithm for distance and heading calculation
+
|No
−
* Coding and Calibration of GPS module
+
|-
−
|  
+
 
−
*
 
−
|
 
 
|-
 
|-
 
! scope="row"| 8
 
! scope="row"| 8
−
| 11/19/2016
+
| Left Sensor
−
|
+
| Gauge
−
* Coding and Calibration of GPS module
+
|No
−
* Individual Unit Testing
 
−
|
 
−
*
 
−
*
 
−
|
 
 
|-
 
|-
 +
 
! scope="row"| 9
 
! scope="row"| 9
−
| 11/26/2016
+
| Middle Sensor
−
|
+
| Gauge
−
* Integration of GPS and compass modules
+
|No
−
* Interfacing GPS with Android, Master and IO controllers
 
−
|
 
−
*
 
−
*
 
−
|
 
 
|-
 
|-
 +
 
! scope="row"| 10
 
! scope="row"| 10
−
| 12/03/2016
+
| Rear Sensor
−
|
+
| An on screen LED that turns off/on
−
* Complete System Testing
+
|Yes
−
|  
+
|-
−
*
+
! scope="row"| 11
−
*
+
| System Status (Heatbeat)
−
|
+
| Gauge
 +
|No
 +
|-
 +
 
 +
! scope="row"| 12
 +
| Speed.
 +
| Meter.
 +
|No
 +
 
 
|-
 
|-
 +
! scope="row"| 13
 +
| Battery Indicator
 +
| Gauge
 +
|No
 
|}
 
|}
 +
 +
==== Hardware Interface ====
 +
The hardware interface for the LCD is through UART for LED it is through GPIO.
 +
LCD Hardware interface:
 +
The LCD controller works on UART communication. Uart-2 on SJONE board is used for sending the data and command to uLCD-32PTU.
 +
We are using uLCD-32PTU to debug and display the important CAN message.  We used this LCD because of following features:
 +
*The uLCD-32PTU is a compact and cost effective Intelligent Display Module packed with plenty of features capable of being an interface controller for a number of applications.
 +
*Built in extensive 4DGL graphics and system library functions.
 +
*Simple UART communication at 9600 Baud rate is used to communicate with SJONE board.
 +
LED hardware interface:
 +
For the LEDs we connected the the positive end to the VCC and the negative end to the GPIO. This was done to prevent the SJOne port from being the current source for a constantly glowing LED.
 +
There are 10 LEDs in total on the car. 4 in the front and 6 in the rear.
 +
<div><ul>
 +
<li style="display: inline-block;">[[File:CMPE_243_F16_SNF_IO_LCD_Connections.JPG|thumb|350px|left|uLCD32PTU Connections]]
 +
<li style="display: inline-block;">[[File:CMPE243_F16_SNF_LCD_REAR_VIEW.JPG|thumb|right|450px|uLCD32PTU Rearview]]
 +
<li style="display: inline-block;">[[File:CMPE_243_F16_LCD_SnF_FRONTVIEW.JPG|thumb|500px|left|uLCD32PTU Frontview]]
 +
<li style="display: inline-block;">[[File:CMPE_243_F16_SNF_LCD_PROGRAMMING_ADAPTER.JPG|thumb|right|700px|uLCD32PTU Programming Adapter]]
 +
</ul></div>
 +
<br clear=all>
  
−
=== Design & Implementation ===
+
==== Software Design ====
−
The design section can go over your hardware and software design.  Organize this section using sub-sections that go over your design and implementation.
+
[[File:CMPE 243 F16 SNF Screen Changes.gif|thumb|500px|center|LCD screen changes]]
 +
<gallery mode ="packed">
 +
File:CMPE_243_F16_SnF_form_0.JPG|Form 0
 +
File:CMPE_243_F16_SnF_form_1.JPG|Form 1
 +
File:CMPE_243_F16_SnF_form_2.JPG|Form 2
 +
File:CMPE_243_F16_SnF_form_3.JPG|Form 3
 +
</gallery>
 +
* Form0: This is the home screen for Spartan and Furious which displays the logo of our team. This screen is displayed when there is no system command from the Master. As soon as the IO receives the master system command the IO displays all the relevant data using periodic callback function.
 +
 
 +
* Form1: This is the screen which is being displayed after the home screen. This screen shows the sensor data, Speed indication, System command status and the direction in which the car is moving.. There are four different gauges for different sensor Data. Each gauge indicates obstacle proximity detected from ultrasonic sensors which are placed on left (L), centre (M), right (R) and rear sensor at back (B) of the car. The direction of the car is indicated using different LEDs for Front(F), Right(R), Left(L), Back(B) indication. The system command LED indicates that master is in sync with all the modules.   
 +
 
 +
* Form2: In this screen IO displays the System Status of all the modules and also the System status given by the master module to all the modules. System status consists of start, stop and Resume status. There are six different LED’s indication the Heartbeat of the modules. There is a battery indicator Gauge which displays the battery life.  
  
−
=== Hardware Design ===
+
* Form3: This is the ‘Geo Status’ screen which shows different parameters such as GPS longitude and latitude, current compass direction and different modes of car.
−
Discuss your hardware design here.  Show detailed schematics, and the interface here.
 
  
−
=== Hardware Interface ===
+
The data is sent to the LCD in specified format.
−
In this section, you can describe how your hardware communicates, such as which BUSes used. You can discuss your driver implementation here, such that the '''Software Design''' section is isolated to talk about high level workings rather than inner working of your project.
+
For sending Gauge, LED, Speedometer data we need to send five bytes of data.<br>
 +
<tt>
 +
Byte1 - Event byte<br>
 +
Byte2 - Object type<br>
 +
Byte3 - Object number<br>
 +
Byte4 - Data byte 1<br>
 +
Byte5 - Check sum
 +
</tt>
  
−
=== Software Design ===
+
For angular meter readings we have six bytes of data to be sent.<br>
−
Show your software design.  For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level.  Do not show the details of the code. For example, do not show exact code, but you may show psuedocode and fragments of code.  Keep in mind that you are showing DESIGN of your software, not the inner workings of it. 
+
<tt>
 +
Byte1 - Event byte<br>
 +
Byte2 - Object type<br>
 +
Byte3 - Object number<br>
 +
Byte4 - Data byte 1<br>
 +
Byte5 - Data byte 2<br>
 +
Byte6 - Check sum<br>
 +
</tt>
  
−
=== Implementation ===
+
For String to be  passed we need to have 3 bytes + each character as data byte + checksum byte.<br>
−
This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.
+
<tt>
 +
Byte1 - Event byte<br>
 +
Byte2 - Object type<br>
 +
Byte3 - Object number<br>
 +
Byte4 - Data byte 1<br>
 +
Byte5 - Data byte 2<br>
 +
Byte6 - Data byte 3<br>
 +
.<br>
 +
.<br>
 +
.<br>
 +
Byte n+3 - Data byte n<br>
 +
Byte n+4  - Check sum<br>
 +
</tt>
 +
The data is sent to the LCD using UART. Following steps should be performed in order to display the readings on LCD.
 +
#Wait for system command from master.
 +
#Once master command has been received, collect CAN data for all information that has to be shown on IO.
 +
#Update the corresponding LCD element, and toggle the LEDs based on data received.
 +
#Switch LCD form every 5 seconds.
 +
#If destination reached, show the destination reached form.
  
 +
<br clear=all>
 +
<gallery widths =500px heights =500px>
 +
File:CMPE 243 F16 SNF LCD FLOWCHART.png|LCD code Flowchart
 +
File:CMPE 243 F16 SNF LED flowchart.png|LED code Flowchart
 +
</gallery>
 +
<br clear=all>
 
=== Testing & Technical Challenges ===
 
=== Testing & Technical Challenges ===
−
Describe the challenges of your project.  What advise would you give yourself or someone else if your project can be started from scratch again?
+
Sensor Technical Challenges and Testing:
−
Make a smooth transition to testing section and described what it took to test your project.
 
  
−
==Sensor and  I/O ==
+
We have used sensor in PW mode. In this mode the major challenge was triggering of the sensor. We had to trigger four sensors in such a way that they do not interfere with each other. In order to tackle this issue we triggered front and rear sensor at same time and after a small delay we triggered right and left sensor at same time.
 +
The second major challenge is sensor reflection from ground and sensor mounting design. We had to mount the sensor with an angle of 20 degrees with the horizontal. Still there were some reflections but they were minimal. We designed 3D print for sensor mounting such that the angle between each sensor was exactly 60 degrees. The beam angle of sensor is 30 degrees in each side.
 +
 
 +
 
 +
 
 +
IO Technical challenges:
 +
 
 +
LCD mounting was the main challenge for IO. We were using LCD and LED for debugging purposes. For LED we connected same GPIO pins for front and back signal pins. So, the issue came with different colour LED’s. The LED which has less resistance draws all the power and only that LED was turning ON and OFF. The other LED was not showing any indication. We had to change both LED’s with same color and then it was working fine.
 +
The second issue was of common ground for LCD. We were sending data using UART and had given a Ground pin connection to LCD from the power source. There was no change in the LCD screens and then we figured out that it was due to no common ground connection.
 +
 
 +
== Motor Controller ==
 
==== Group Members ====
 
==== Group Members ====
−
*'''''[http://www.linkedin.com/in/bhushanmuthiyan Bhushan Muthiyan]<br> '''''
+
*'''''[http://www.linkedin.com/in/srinivasanshilpa Shilpa Srinivasan]<br> '''''
−
*'''''[http://www.linkedin.com/in/kparameswaran Karthik Parameswaran]<br>'''''
+
 
 +
=== Design & Implementation ===
 +
The motor controller is responsible for generating the driving and steering action of the car. For this purpose, we have two types motors viz DC motor for driving and Servo motor which is used for changing directions of the car. The motor controller is also interfaced with a speed encoder for generating a feedback mechanism to automatically control and monitor the speed of the car.
 +
Our car came equipped with a Servo motor and brushed DC motor which is connected Electronic Speed Control (ESC).
 +
 
 +
=== Hardware Design ===
 +
[[File:CMPE243_F16_SnF_MotorHardwareInterface.png|frame|left|200px|Motor Hardware Schematics]]  
  
−
=== Schedule ===
 
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
−
! scope="col"| Week#
+
! scope="col"|  
−
! scope="col"| Date
+
! scope="col"| SJOne Pin Diagram
−
! scope="col"| Task
+
! scope="col"|  
−
! scope="col"| Actual
+
|-
−
! scope="col"| Status
+
! scope="col"| Sr.No
 +
! scope="col"| Pin Number
 +
! scope="col"| Pin Function
 +
 
 
|-
 
|-
 
! scope="row"| 1
 
! scope="row"| 1
−
| 10/01/2016
+
| P0.0
−
|
+
| CAN RX
−
* Order components
+
 
−
|  
 
−
* Read through wiki to find out components used in earlier projects.<br>
 
−
* Searched if better components were available.
 
−
* Ordered additional ultrasonic sensors and LCD.
 
−
| Complete
 
 
|-
 
|-
 
! scope="row"| 2
 
! scope="row"| 2
−
| 10/08/2016
+
| P0.1
−
|
+
| CAN TX
−
* Follow up on ordered parts
+
 
−
|
 
−
* Parts received on 7th Oct.
 
−
*Started working on sensors.
 
−
| Complete
 
 
|-
 
|-
 
! scope="row"| 3
 
! scope="row"| 3
−
| 10/15/2016
+
| P2.0
−
|
+
| Servo motor
−
*Design basic sensor algorithm for obstacle detection.
+
 
−
*Download software for LCD.
 
−
|  
 
−
*
 
−
|
 
 
|-
 
|-
 
! scope="row"| 4
 
! scope="row"| 4
−
| 10/22/2016
+
| P2.1
−
|
+
| DC motor
−
* Design layout for LCD screen
 
−
* Mount ultrasonic sensor on car and test it.
 
−
|
 
−
*
 
−
|
 
 
|-
 
|-
 
! scope="row"| 5
 
! scope="row"| 5
−
| 10/29/2016
+
| P2.5
−
|
+
| Speed Encoder
−
* Establishing basic CAN communication.
+
 
−
* Integrate IR sensor for gauging speed.
 
−
|
 
−
*
 
−
|
 
−
|-
 
−
! scope="row"| 6
 
−
| 11/05/2016
 
−
|
 
−
* Collaborating with other modules for first demo.
 
−
* Fine-tuning algorithms for sensor and IR.
 
−
|
 
−
*
 
−
|
 
−
|-
 
−
! scope="row"| 7
 
−
| 11/12/2016
 
−
|
 
−
*Develop LCD code for displaying all sensor information and car vitals.
 
−
*Decide upon additional I/O such as lights.
 
−
|
 
−
*
 
−
|
 
−
|-
 
−
! scope="row"| 8
 
−
| 11/19/2016
 
−
|
 
−
*Integrate sensor and I/O code.
 
−
*Facilitate Motor module to test with IR sensor.
 
−
|  
 
−
*
 
−
|
 
−
|-
 
−
! scope="row"| 6
 
−
| 11/26/2016
 
−
|
 
−
* Testing and integration with all modules.
 
−
|
 
−
*
 
−
|
 
−
|-
 
−
! scope="row"| 9
 
−
| 12/03/2016
 
−
|
 
−
* Fine tuning and debugging of the whole module.
 
−
|
 
−
*
 
−
|
 
−
|-
 
 
|}
 
|}
  
−
=== Design & Implementation ===
 
−
The design section can go over your hardware and software design.  Organize this section using sub-sections that go over your design and implementation.
 
  
−
=== Hardware Design ===
+
<br clear=all>
−
Discuss your hardware design here. Show detailed schematics, and the interface here.
+
 
 +
*'''Hardware Specifications'''
 +
 
 +
[[File:CMPE243_F16_SnF_DCMotor.png|thumb|left|200px|DC Motor]]
 +
=====1. DC Motor =====
 +
Our car came with Titan 12T 550 brushed motor and waterproof ESC. The ESC drives the DC motor based on the Pulse Width modulation (PWM) applied to it. The power supply required for this motor is 8.4 V. Maximum speed of upto 30mph can be achieved. The rotational speed is proportional to the EMF generated in its coil and the torque is proportional to the current.The main connection pins driving the motor are VCC,GND and the Control pin (PWM). The pin P2.1 of SJ-one board is connected to supply the required PWM to the motor.
 +
The basic working principle of DC motor is illustrated in the following figure :
 +
Since the preprogrammed controller has to be replaced by using our design ,the DC motor is then tested with Digital Oscilloscope for getting the frequency of operation and equivalent PWM values for full throttle condition in the forward as well as backward condition.
 +
It was observed from the waveform that the frequency of operation is 100Hz. The range of operational duty cycle is 10% to 20% with 15% being the neutral value or the stop condition.
 +
In order to accelerate the car a PWM value in the range of 15.6%-20.0% is applied. The 15.6 is the minimum pickup PWM that should be supplied in order to get the car moving at full load. <br> <br>
 +
 
 +
[[File:CMPE243_F16_SnF_ServoMotor.png|thumb|left|140px|Servo Motor]]
 +
=====2. Servo Motor =====
 +
The servomotor used in the car is #2056 a waterproof all weather-action and double the steering power as compared to standard servos. The servo motor is responsible for controlling the steering action of right or left by applying a suitable PWM pulse. The servo motor can be driven with 3.3 V power supply. The pin P2.0 of SJ-one board is connected to supply the required PWM to the motor. After testing the servo motor, we found that the frequency of operation is 100Hz and the operational duty cycle range is 10.0%-20.0% with 15% being the neutral value. For a full right deflection, we provide input PWM pulse ranging from 15.0-20.0% and for full deflection to the left we apply 10.0-15.0% of PWM. <br>
 +
 
 +
 
 +
<br>
 +
 
 +
 
 +
 
 +
 
 +
[[File:CMPE243_F16_SnF_DSO.png|thumb|centre|700px|Digital Oscilloscope readings for the motors]]<br>
 +
 
 +
[[File:CMPE243_F16_SnF_HallEffectSensor.png|thumb|left|300px|Hall-Effect Principle.]]
 +
=====3. Speed Sensor =====
 +
The speed feedback is monitored through the speed encoder which works on the Hall-effect principle.
 +
The Hall-effect speed sensor works as a transducer whose output voltage varies in response to the magnetic field.
 +
The sensor is mounted on the Spur gear instead of the wheel. The sensor would detect the rotation of axle. The motor controller would detect whenever the magnet is aligned with the sensor. This would generate a pulse. The pulse is detected in the form of rising-edge interrupt.
 +
This gives the wheel rotation count. The wheel rotates for every 1/4th rotation of the spur gear. The rotation count can then be converted to rpm to calculate the speed of the car. <br><br><br><br><br>
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
  
 
=== Hardware Interface ===
 
=== Hardware Interface ===
−
In this section, you can describe how your hardware communicates, such as which BUSes used. You can discuss your driver implementation here, such that the '''Software Design''' section is isolated to talk about high level workings rather than inner working of your project.
+
The CAN bus is used to send and receive messages to and from the Master Controller. The motor controller receives driving and steering signals from the master. The speed calculation is performed using the speed sensor and is sent on the bus, which will be received by the IO controller for display purposes.
  
 
=== Software Design ===
 
=== Software Design ===
−
Show your software design.  For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code. For example, do not show exact code, but you may show psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.
+
The following diagram describes the flow of the software implementation for the motor driver and speed feedback mechanism.
 +
[[File:CMPE243_F16_SnF_Flowchart.png|frame|centre|100px|Flowchart.]]
 +
[[File:CMPE243_F16_SnF_Flowchart2.png|frame|centre|100px|Speed Feedback Implementation.]]
  
 
=== Implementation ===
 
=== Implementation ===
−
This section includes implementation, but again, not the details, just the high level.  For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.
+
The motor controller receives all its signals from Master controller from the CAN bus.
 +
The motor controller receives the steer and drive command from the master. The motor controller receives the System start command which boots and decodes further drive signals to the motor controller. Upon receiving the drive command the motor controller decodes the steering action. Upon receiving suitable data about the obstacle from sensor controller the master controller relays appropriate steering action. To achieve better performance in steering, the turn is categorized as FULL and HALF. This gives better precision in turning.
 +
*Speed Regulation:
 +
Upon detection of uphill the pulse received from the speed encoder reduces. This is detected and the motor feedback is designed such that the speed is increased by providing higher value of PWM value to drive the DC motor. Similarly, for downhill the pulse count received increases which is detected by the speed encoder and the speed is reduced by applying reduced PWM.
  
 
=== Testing & Technical Challenges ===
 
=== Testing & Technical Challenges ===
−
Describe the challenges of your project. What advise would you give yourself or someone else if your project can be started from scratch again?
+
*Wheel Alignment Error
−
Make a smooth transition to testing section and described what it took to test your project.
+
Though the neutral value of PWM is 15% at which the servo is supposed to be aligned straight. In practice, however when we tested the car for straight run slight deflection towards right was observed when the PWM pulse width was set to 15.0 %. Thus, to correct this, we provided correction value of -0.98 giving a resultant PWM pulse width of 14.02%. Thus, we fixed the wheel alignment and obtained the desired straight path traversal.
 +
<br>
 +
*Speed Sensor Assembly
 +
The speed encoder was assembled on the spur gear of the car. The installation at first was such that outer fitting was large and was avoiding the pulse trigger by the magnet.As a result of which we were unable to modulate speed.Issue was resolved by using the correct outer assembly of the gear which generated the speed feedback.
  
 
== Master Controller ==
 
== Master Controller ==
Line 618: Line 1,249:
 
*'''''[http://www.linkedin.com/in/sukriti-choudhary-16550b104 Sukriti Choudhary]<br> '''''
 
*'''''[http://www.linkedin.com/in/sukriti-choudhary-16550b104 Sukriti Choudhary]<br> '''''
  
−
=== Schedule ===
+
=== Introduction and Responsibilities ===
 +
 
 +
Master controller is the brain of the car.<br>
 +
All the decisions are taken by the master module. Some of the major responsibilities of the master module are:<br>
 +
 
 +
* System command (Initial Start) : Upon successful connection with Android app, master command will send as system start command to all the other modules on the CAN bus. This command advises all the modules to start their processing(similar to wake up).
 +
* Obstacle avoidance : Based on the sensor values, master will decide the direction to be taken by the motor.<br>
 +
* GPS data: Depending upon the GPS calculated direction and obstacle data received from sensor module, master controller will decide the steer and drive of the motor.<br>
 +
* Determine if all the modules on the bus are active or inactive.<br>
 +
 
 +
The master controller using the data from other modules, drives the car safely to the destination.
 +
 
 +
=== Hardware Design ===
 +
 
 +
*Interface of CAN Bus with six SJ-One controller boards on PCB was designed.
 +
*Ribbon Cables were used instead of individual jumper wires to assist in designing less complex circuit.
 +
 
 +
 
 +
[[File:CMPE243_F16_SnF_Master_CAN_Interface.jpg|thumb|center|700px|Interface with the CAN Hardware]]
 +
 
 +
=== Software Design ===
 +
 
 +
Master Controller needs to periodically receive and transmit updated data from all the modules in order to make an efficient decision. Based on the priority of the data, corresponding CAN messages are parsed in 100Hz, 10Hz or 1Hz periodic scheduler tasks respectively. Data received can be viewed and traced in real time using PCAN View or BUS Master tool.
 +
 
 +
=== Software Implementation ===
 +
The diagram below details out the flow of data to and from the Master Controller.<br>
 +
 
 +
[[File:CMPE243_F16_SnF_Master_Block.gif|thumb|700px|center|Master Controller Execution Flow]]
 +
 
 +
==== Heartbeat ====
 +
 
 +
Master Controller is responsible to identify if all the modules are active or inactive. All the modules send the heartbeat messages on the CAN Bus every 1Hz. If the heartbeat message is not received from any module, master marks the system status of the module as inactive. The system status message is update at run time on the I/O and the app. User can then reset the inactive module.
 +
 
 +
The code snippet for the receiving heartbeat messages and determining system status is as follows: <br>
 +
 
 +
if(dbc_decode_BLE_HEARTBEAT(&ble_heartbeat_cmd, can_msg.data.bytes, &can_msg_hdr))
 +
    system_status_message.MASTER_SYSTEM_STATUS_ble = 1;
 +
if(dbc_decode_SENSOR_HEARTBEAT(&sensor_heartbeat_cmd, can_msg.data.bytes, &can_msg_hdr))
 +
    system_status_message.MASTER_SYSTEM_STATUS_sensor = 1;
 +
if(dbc_decode_GEO_HEARTBEAT(&geo_heartbeat_cmd, can_msg.data.bytes, &can_msg_hdr))
 +
    system_status_message.MASTER_SYSTEM_STATUS_geo = 1;
 +
if(dbc_decode_IO_HEARTBEAT(&io_heartbeat_cmd, can_msg.data.bytes, &can_msg_hdr))
 +
    system_status_message.MASTER_SYSTEM_STATUS_io = 1;
 +
if(dbc_decode_MOTOR_HEARTBEAT(&motor_heartbeat_cmd, can_msg.data.bytes, &can_msg_hdr))
 +
    system_status_message.MASTER_SYSTEM_STATUS_motor = 1;
 +
 
 +
 
 +
To determine the direction and throttle of the car, master controller needs the data from sensor and Geo module. These data are critical for the system and are parsed in 10Hz periodic tasks.
 +
After the master receives BLE_CMD = START, master will send SYSTEM_CMD= START command to all of the modules, which notifies them that the Bluetooth communication via app has been initiated.
 +
The car is capable of reaching a destination or just running while avoiding obstacles with no destination set.
 +
The software design of the master controller supports two modes for the car:
 +
 
 +
==== Free Run mode ====
 +
 
 +
* For switching to free run mode, the “FREE RUN” button needs to be selected from the app.
 +
* As per the sensor data, the movement of the car is decided by the master controller.
 +
* By default the motor is commanded to move straight.
 +
* If there is an obstacle in the middle sensor, then the sensor data for left and right sensor is checked.
 +
* If there is an obstacle at a very short distance, critical obstacle bit is set and car is first stop.
 +
* When the car needs to stop due to obstacles, reverse sensor value is checked.
 +
* The car stops only when there are obstacles in all directions or user sends Stop from the app.
 +
* The following table depicts the motor command sent by master to the motor controller as per the sensor values.
 +
 
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
−
! scope="col"| Week#
+
! scope="col"| Sr no
−
! scope="col"| Date
+
! scope="col"| Left sensor value
−
! scope="col"| Task
+
! scope="col"| Middle sensor value
−
! scope="col"| Actual
+
! scope="col"| Right sensor value
−
! scope="col"| Status
+
! scope="col"| Critical value
 +
! scope="col"| Rear sensor value
 +
! scope="col"| Motor Command
 +
 
 +
|-
 +
! scope="row"| 0
 +
| 0
 +
| 0
 +
| 0
 +
| 0
 +
| X
 +
| STRAIGHT
 +
 
 
|-
 
|-
 
! scope="row"| 1
 
! scope="row"| 1
−
| 10/01/2016
+
| 0
−
|
+
| 0
−
* Implement basic CAN communication CAN between two SJ-One Boards
+
| 1
−
|  
+
| 0
−
* Successfully tested CAN communication between two SJ-One boards.<br>
+
| X
−
| Complete
+
| HALF RIGHT
 +
 
 
|-
 
|-
 
! scope="row"| 2
 
! scope="row"| 2
−
| 10/08/2016
+
| 0
−
|
+
| 1
−
* Research on the CAN bus, tasks and scheduling.<br>
+
| 0
−
* Decision regarding flow of the master controller.
+
| 0
−
|  
+
| X
−
* Learnt about the working of CAN bus and decided on flow for the master controller.
+
| LEFT
−
| Complete
+
 
 
|-
 
|-
 
! scope="row"| 3
 
! scope="row"| 3
−
| 10/15/2016
+
| 0
−
|
+
| 1
−
* Decision making regarding Node address and message ID's for CAN controller.
+
| 1
−
|  
+
| 0
−
*
+
| X
−
|In Progress
+
| RIGHT
 +
 
 
|-
 
|-
 
! scope="row"| 4
 
! scope="row"| 4
−
| 10/22/2016
+
| 1
−
|
+
| 0
−
* Interfacing master controller with Sensor Controller module.
+
| 0
−
|
+
| 0
−
*
+
| X
−
|
+
| HALF LEFT
 
|-
 
|-
 
! scope="row"| 5
 
! scope="row"| 5
−
| 10/29/2016
+
| 1
−
|
+
| 0
−
* Basic interfacing of master controller with motor module.
+
| 1
−
|  
+
| 0
−
*
+
| X
−
|
+
| STRAIGHT
 +
 
 
|-
 
|-
 
! scope="row"| 6
 
! scope="row"| 6
−
| 11/05/2016
+
| 1
−
|
+
| 1
−
* Interface with the motor and Sensor module for the first demo.
+
| 0
−
* Testing and debugging.
+
| 0
−
|  
+
| X
−
*
+
| LEFT
−
|
+
 
 
|-
 
|-
 
! scope="row"| 7
 
! scope="row"| 7
−
| 11/12/2016
+
| 1
−
|
+
| 1
−
* Interface of master controller with GPS module.
+
| 1
−
* Develop kill switch mechanism.
+
| 0
−
|  
+
| 0
−
*
+
| REVERSE
−
|
+
 
 
|-
 
|-
 
! scope="row"| 8
 
! scope="row"| 8
−
| 11/19/2016
+
| 1
−
|
+
| 1
−
* Develop heartbeat mechanism to check health of each of the modules.
+
| 1
−
* Integrate master controller with android module.
+
| 0
−
|  
+
| 1
−
*
+
| STOP
−
*
 
−
|
 
 
|-
 
|-
 
! scope="row"| 9
 
! scope="row"| 9
−
| 11/26/2016
+
| X
−
|
+
| X
−
* Integration of I/O module.
+
| X
−
* Testing and integration with all modules.
+
| 1
−
|  
+
| 0
−
*
+
| REVERSE
−
*
 
−
|
 
 
|-
 
|-
 
! scope="row"| 10
 
! scope="row"| 10
−
| 12/03/2016
+
| X
−
|
+
| X
−
* Fine tuning, debugging and integration.
+
| X
−
|  
+
| 1
−
*
+
| 1
−
*
+
| STOP
−
|
 
 
|-
 
|-
 +
 
|}
 
|}
  
−
=== Design & Implementation ===
+
* When STOP button is selected from the app,the BLE will advise the same to master controller and master will send SYSTEM_CMD= STOP to all the modules. This stop command notifies them that the Bluetooth communication via app has been deactivated. <br>
−
The design section can go over your hardware and software design. Organize this section using sub-sections that go over your design and implementation.
+
 
 +
 
 +
[[File:CMPE243_F16_SnF_Free_Run_Flowchart.png|thumb|center|700px|Free Run Mode Flow Chart]]
 +
 
 +
==== Navigation mode ====
 +
 
 +
* For switching to navigation mode, the “NAVIGATION MODE” button needs to be selected from the app.
 +
* In this mode, Geo module sends the desired direction to the master controller.
 +
* The master controller will check if there is any obstacle in the desired path.
 +
* In case of obstacle, car moves as per the obstacle avoidance algorithm (free run mode).
 +
* Once Destination Reached signal is received from the Geo module, the car stops. <br>
  
−
=== Hardware Design ===
 
−
Discuss your hardware design here.  Show detailed schematics, and the interface here.
 
  
−
=== Hardware Interface ===
+
[[File:CMPE_243_F16_SnF_Navigation_Mode_Flowchart.png|thumb|center|1000px|Navigation Mode Flow Chart]]
−
In this section, you can describe how your hardware communicates, such as which BUSes used.  You can discuss your driver implementation here, such that the '''Software Design''' section is isolated to talk about high level workings rather than inner working of your project.
 
  
−
=== Software Design ===
+
== Common Technical Challenges ==
−
Show your software design.  For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code.  For example, do not show exact code, but you may show psuedocode and fragments of code.  Keep in mind that you are showing DESIGN of your software, not the inner workings of it.   
+
=== Issue 1 ===
 +
One of the most unexpected issue faced during testing, was we were unable to receive data from motor and sensor module during testing for demo1. After debugging, we realized that the ribbon cable we purchased was meant for a special purpose and was shorted internally as shown in the picture because of which we were unable to receive data from the CAN bus.   
  
−
=== Implementation ===
 
−
This section includes implementation, but again, not the details, just the high level.  For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash.  You can include sub-sections for each of your component implementation.
 
  
−
=== Testing & Technical Challenges ===
+
[[File: CMPE243_F16_SNF_Ribbon_breakout.PNG|thumb|center|500px|Ribbon Breakout]]
−
Describe the challenges of your project. What advise would you give yourself or someone else if your project can be started from scratch again?
+
[[File: CMPE243_F16_SNF_Ribbon_cable.png|thumb|center|800px|Ribbon Cable]]
−
Make a smooth transition to testing section and described what it took to test your project.
 
  
 
== Conclusion ==
 
== Conclusion ==
−
Conclude your project here.  You can recap your testing and problems.  You should address the "so what" part here to indicate what you ultimately learnt from this project.  How has this project increased your knowledge?
 
  
−
=== Project Video ===
+
This project has helped each one of us grow, not just academically, but professionally as well. This project did achieve the goals it promised, these were:
−
Upload a video of your project and post the link here.
+
*CAN: Teaching us to work with the CAN bus and protocol; a simple, robust and noise immune mode of communication and using DBC files as a method of managing CAN messages.
 +
*GIT: Using GIT as a method of continuous integration and improve productivity. GIT allowed us to work independent of our schedules, boosting our productivity beyond the time the team members met.
 +
*Team Work: Working in a fairly large group gave us a real sense of team work and collaboration.
 +
*Professionalism and accountability.
 +
 
 +
On testing the car we found a lot of practical hurdles that we had to overcome. Debugging issues was a large part of our efforts to improve the working of our car. To mention a few:
 +
*Hardware issues:
 +
** Ribbon Cable: Issues with ribbon cables, we found the hard way that the ribbon cable we initially used was for a specific purpose making it incompatible with our boards.
 +
**Voltage fluctuation disrupting the CAN bus: Inconsistent soldering on on of the power rails, caused the CAN bus to fail altogether.
 +
*Bluetooth bridge: Maintaining a Bluetooth connection between different activities in the app was a problem.
 +
*Sensor: A section of code was rearranged to solve a problem that prevented the sensor from sending messages to the CAN bus.
 +
*I/O: The I/O module is receiving a large amount of data, causing a task overrun. This was fixed by re-prioritizing the display and rearranging the code.
 +
 
 +
To the teams that are designing their car:
 +
* Use a faster sensor and apply filters like a median or Gaussian filter to improve sensor performance.
 +
* Ensure hardware connections are tested thoroughly.
 +
* Start with the implementation for the Geo module early.
 +
* Ensure that your Android App can communicate consistently with SJOne board.
 +
=== Project Videos ===
 +
 
 +
[https://youtu.be/dsfW-ZqOqjA CMPE243_F16_Spartan_and_Furious]
 +
[https://youtu.be/89XIqO05p18 Demo Day Video]
  
 
=== Project Source Code ===
 
=== Project Source Code ===
Line 747: Line 1,476:
 
== References ==
 
== References ==
 
=== Acknowledgement ===
 
=== Acknowledgement ===
−
Any acknowledgement that you may wish to provide can be included here.
+
We would like to acknowledge the following people for their help in completing this project:
 +
*Preet for his invaluable teachings.
 +
*The ISAs for their great advice and tips.
 +
*[https://www.linkedin.com/in/gvsiddharth Siddarth] for helping with the design for our 3D mount.
 +
*Maxbotix for a generous student discount on their product.
 +
*Microchip for the free CAN ICs.
 +
*[http://www.cratustech.com/ Cratus Technologies] for letting us use their 3D printer.
  
 
=== References Used ===
 
=== References Used ===
−
List any references used in project.
+
*[http://www.nxp.com/documents/user_manual/UM10360.pdf LPC_USER_MANUAL]
−
 
+
*[http://www.microchip.com/wwwproducts/en/en010405 CAN transceiver]
−
=== Appendix ===
+
*[https://en.wikipedia.org/wiki/Haversine_formula Haversine Formula Wikipedia]
−
You can list the references you used.
+
*[https://en.wikipedia.org/wiki/Magnetometer Magnetometer Wikipedia]
 +
*[http://ww1.microchip.com/downloads/en/DeviceDoc/21667f.pdf MCP2551 Datasheet]
 +
*[https://en.wikipedia.org/wiki/Hall_effect_sensor Hall Effect Sensor Wikipedia]
 +
*[https://cdn-shop.adafruit.com/datasheets/GlobalTop-FGPMMOPA6H-Datasheet-V0A.pdf Ultimate GPS Adafruit]
 +
*[http://www.4dsystems.com.au/product/uLCD_32PTU/ uLCD-32PTU]
 +
*[http://www.maxbotix.com/documents/LV-MaxSonar-EZ_Datasheet.pdf Maxbotix Ultrasonic Datasheet]
 +
*[https://learn.adafruit.com/adafruit-ina219-current-sensor-breakout/downloads Adafruit Ina219 current sensor]
 +
*[https://www.sparkfun.com/products/12582 SparkFun Bluetooth Modem - BlueSMiRF Gold]
 +
*[https://developer.android.com/guide/topics/connectivity/bluetooth.html Android Bluetooth API Guid]
 +
*[https://developers.google.com/maps/documentation/android-api/ Maps Android API]
 +
*[https://traxxas.com/sites/default/files/Slash%204x4%20RPM.pdf RPM sensor 6520 Installation Guide]
 +
*[https://traxxas.com/support/Programming-Your-Traxxas-Electronic-Speed-Control Configuration of Electronics Speed Control]

Latest revision as of 23:21, 15 December 2017

Contents

Spartan And Furious

Android Application controlled Self-Driving Car using CAN bus.


CMPE243 F16 SNF MAIN WIKI IMAGE.JPG

Abstract

Embedded systems are unique, they tend to take real world inputs, such as light, and make meaningful applications of this data. A self driving car is the epitome of an embedded system, it takes all kinds of information through various sensors and try to give results in the form of travelling from point A to point B. In this project, we attempt to create a self driving car with the aim of putting into practice the knowledge gained through the CMPE 243 course.

The key features of the self driving car are:

  • Android App controlled start/stop and source/destination selection of the vehicle.
  • Navigation of the car on the desired path.
  • Obstacles avoidance in the path.
  • Closed loop feedback to maintain speed uphill or downhill.


The system consists of six SJOne Boards that run FreeRTOS and communication between the boards is established using the robust and high speed CAN Communication BUS.

System Diagram

Objectives & Introduction

In this project, we aim to use the CAN bus to create a self-driving car that can travel between two pre-determined points. The path for the car is given through a mobile application based on the android operating system. The car then navigates between these points by taking location feedback through a GPS system and using ultrasonic sensors embedded on the car to avoid obstacles in the path of the car. IO systems present on the car give us pertinent information about the status of the car and the onboard processing.

The Objectives for this project are:

  • The car must be able to interact with a Bluetooth enable mobile application and provide a path that the car must follow.
  • Given the path to follow, the car must use a GPS module to gather location feedback and route the car toward its destination.
  • The car must be able to determine obstacles in its path using ultrasonic sensors and avoid.
  • The car must be able to control its speed in various terrain using a speed feedback mechanism.
  • Provide meaningful information about the car’s present status using IO modules such as LEDs and LCD.
  • A master board must be able to determine the correct action required for the data gathered through sensors and GPS feedback.
  • All the modules must communicate with each other over the CAN bus.
  • Document the findings in this report for future classes to reference so that they may improve this design.

Team Members & Responsibilities

Schedule

Legend:

Motor Controller , Master Controller , Android Controller, Geo Controller, Sensor and I/O Controller , Team Goal

Week# Date Task Actual Status
1 9/17/2016
  • Purchasing RC car.
  • Purchased RC car.
 Complete.
2 9/24/2016
  • Individual module distribution.
  • Project report setup.
  • Git setup.
  • Order components for individual modules.
  • Members identified for modules.
  • Wikipage project report template and Git were setup.
  • Ordered GPS module and CAN transceivers.
 Complete
3 10/01/2016
  • Define scope of each module.
  • Determine Git flow.
  • Follow up on component procurement.
  • Determining and analyzing the duty cycle for servomotor and DC motor of the car.
  • Implement basic CAN communication CAN between two SJ-One Boards.
  • Initial flow of each module defined.
  • Identified the branches and decided on merge process.
  • Ordered additional ultrasonic sensors and LCD.
  • Tested the car servo and DC motor using Digital Oscilloscope.
  • Observed and noted the duty cycle wave forms .
  • Successfully tested CAN communication between two SJ-One boards.
 Complete
4 10/08/2016
  • Create branches in Git
  • Follow up on component procurement
  • Basic testing of Servo and DC motor.
  • Testing speed of car with variable PWM.
  • Research on the CAN bus, tasks and scheduling.
  • Decision regarding flow of the master controller.
  • Download software for LCD
  • Created Master branch on Git
  • All ordered parts received by 10/07.
  • Implemented test code to interface SJOne board with a servo motor to control the direction and verified the same on the car.
  • Speed testing in progress.
  • Learnt about the working of CAN bus and decided on flow for the master controller.
  • Installed 4D System Workshop4 IDE (for LCD).
 Complete
5 10/15/2016
  • Developing drivers for both motors.
  • Android app prototype.
  • Parse GPS data and format the data to be transmitted.
  • Decision making regarding various messages to be sent on CAN bus.
  • Design basic sensor algorithm for range finding.
  • Algorithm developed for both the motors.
  • Basic App Screen layout designed.
  • GPS latitude & longitude coordinates extracted from NMEA format.
  • Identified various messages for different nodes.
  • Designed basic algorithm for range finding.
Complete
6 10/22/2016
  • Define CAN signals for each module.
  • Testing the car with developed drivers.
  • Interface Bluetooth module with SJ-One board.
  • Implement source code and fetch Magnetometer reading.
  • Design of CAN bus hardware.
  • Test basic working for IR.
  • CAN signals along with their priorities identified (DBC file format generated).
  • Testing for developed motor drivers in progress.
  • Testing of Bluetooth interface in progress.
  • Implemented the Magnetometer source code, Testing in progress.
  • Tested for hardware integrity.
  • Developed algorithm for obstacle detection.
 Complete.
7 10/29/2016
  • Fine tuning motor control code.
  • Transmitting and receiving messages between Android App and SJ-One board.
  • Test the extracted GPS data for consistency and check the update rate.
  • Basic interfacing of master controller with motor module.
  • Integrate IR sensor for gauging speed.
  • Testing in Progress for the motor control code.
  • Successfully established communication interface between app and SJ-one board
  • Latitude and Longitude parsed data tested, observed few NMEA strings with wrong checksum values.
  • Testing in Progress of the interface over CAN bus.
  • Developed algorithm for obstacle detection.
  • Speed sensing was delegated to motor team as suggested by Preet.
Complete.
8 11/05/2016
  • Integration of modules for first demo.
 Integration and Testing completed for the first demo. Complete.
9 11/12/2016
  • Design of Feedback Control mechanism for car.
  • Initial algorithm development of GPS module for heading calculation.
  • Integration of master module with bluetooth module .
  • Develop LCD code for displaying all sensor information and car vitals.
  • Decide upon additional I/O such as lights.
  • Developed algorithm for motor feedback mechanism.
  • Initial algorithm developed for GPS heading calculation and tested.
  • Communication between bluetooth and master module established successfully .
  • Created project in Workshop4 IDE for all elements to be displayed by LCD.
  • Found UART commands to control each element in the LCD display.
  • I/O hardware was decided upon.
 Complete.
10 11/19/2016
  • Speed synchronization of car using speed sensor and testing.
  • Interfacing Android controller with the GPS module
  • Algorithm for distance and heading calculation.
  • Coding and Calibration of GPS module.
  • Interface of master module with I/O module and testing to ensure predicted output.
  • Integrate sensor and I/O code.
  • Integrated speed sensor for calculating the speed and controlling motor speed.
  • Interface of Android controller with the GPS module conducted successfully.
  • Algorithm implemented for distance and heading calculation.
  • Calibration of Magnetometer ongoing.
  • Communication between I/O module and master module established successfully .
  • LCD code completed and sensors adjusted to work in tandem with obstacle avoidance logic.
Complete
11 11/26/2016
  • Testing and debugging for second demo.
  • Integration and testing complete for second demo.
 Complete
12 12/03/2016
  • Fine tuning, debugging and integration.
  • Algorithm to be implemented for Direction: Half Left, Left, Right, Half Right and Straight etc
  • Initial Testing to be done with default hard-coded GPS checkpoint values
  • Fine tuning on Geo, Android and I/O module algorithm.
  • Compass mounted on the car and re-calibration done.
  • Algorithm implemented for steer command.
  • Testing completed with default hard-coded GPS coordinates
  • Calibrated the steer command angle range and the distance offset value while reaching the checkpoint
Complete
13 12/10/2016
  • Final testing and fine tuning
  • Report preparation
  • Final testing done.
Complete

Parts List & Cost

Item# Part Description Vendor Qty Cost
1 SJ One Board (LPC 1758) From Preet 6 $480
2 RC Car Sheldon Hobbyist 1 $309.99
3 Accelerometer/Magnetometer LSM303 Adafruit 2 $40.00
4 Bluetooth Module Sparkfun 1 $34.95
5 CAN Transceivers From Microchip. 10 $0 (Free Samples)
6 Battery Pack From Sheldon Hobbist 1 $49.99
7 Ultra Sonic Sensor From Maxbotix 5 $91.15 (at 40% student discount)
8 LCD Display From Digikey 1 $94.21
9 GPS Module From Adafruit 1 $43.34
10 General Components From HSC electronics - $83.17
11 DC Current Sensor From Adafruit 1 $14.39
12 PCB From Amazon 1 $10.66
13 Corrugated Sheet for chasis From Home Depot 1 $6.74
14 PCAN dongle From Preet 1 $0

Car Framework and Components

Stampede 4X4 is built on the advanced shaft-driven 4WD system and innovative modular design of the Slash 4X4. The chassis fully integrates the electronics and battery compartment for an efficient and compact layout, and maintains the high center ground clearance. It uses just three gear meshes to drive all four wheels, eliminating the need for a multi-gear transmission. The highly efficient drive train spins effortlessly on rubber-sealed ball bearings, and is integrated seamlessly into the unique chassis for optimum performance and easy maintenance. A single center driveshaft connects the front and rear drive assemblies for maximum power transfer. To harness the torque of the Titan 12-turn motor, Traxxas bolted in the high-performance, waterproof XL-5 electronic speed control. EZ-Set one-button setup makes it easy to adjust or change profiles.

Car Framework

CAN BUS Design

CAN Communication is used to communicate between all the boards. CAN Protocol requires the bus to be terminated using two 120 Ohm resistors. CAN is a broadcast bus. Based on the .dbc file, each module will transmit only selected messages. Receiving of the messages is enabled by filtering. Module can be configured to receive all messages or receive selected messages.


CAN Interface



CAN 11-bit ID Format

We have used 11-bit ID format for all the messages. The message ids have been defined to represent the transmitter, receiver and the message.

SRC DST MSG
3 bits (10-8) 4 bits (7-4) 4 bits (3-0)

Controller ID Table

Each module has been assigned a number. This number is used to define the message ids.

Controller ID Controller Type
0 System Command
1 Master Controller
2 Sensor Controller
3 BLE Controller
4 Geo Controller
5 Motor Controller
6 I/O Controller

CAN Communication Table

The table indicates the messages based on the transmitter.

Sr. No Message ID Message function Receivers
System Commands
1 10 System communication command Master
Master Controller Commands
2 100 Master System Command for the all modules to start or stop processing BLE, Geo, I/O, Motor, Sensor
3 151 Steer and Drive command for the Motor module Motor, I/O
4 162 Display the active state of each module BLE, I/O
Sensor Controller Commands
5 211 Obstacle Data Master, I/O
6 214 Heartbeat Master
7 263 Battery Health I/O
BLE Controller Commands
8 314 Heartbeat Master
9 341 Checkpoints Geo
Geo Controller Commands
10 411 Calculated Direction for the car Master
11 413 Destination Reached flag Master, BLE, I/O
12 414 Heartbeat Master
13 431 Start point BLE, I/O
14 461 Compass data I/O
Motor Controller Commands
15 514 Heartbeat Master
16 561 Car speed I/O
I/O Controller Commands
17 614 Heartbeat Master

DBC File

DBC file is designed based on the designed CAN messages and signals. Preet's python script is used to auto generate CAN communication related structures and functions. Each module will generate its specific generated_can.h by changing the module name in 'pre_build.sh' file. The following is the example of generating the auto code for master module. 


                  python ../_can_dbc/dbc_parse.py -i ../../snf.dbc -s MASTER > ../_can_dbc/generated_can.h


The DBC file can be found at the following link:

Can Bus analyzer

The PCAN-USB adapter enables simple connection to CAN networks. Bus Master software and PCAN-View software has been used to read and debug CAN messages. Bus Master requires DBC file to be converted to .dbf file. The messages can be viewed in very detailed format in the Bus Master. Both the tools along with PCAN dongle are very useful in debugging the CAN communication. It is also possible to record the logs of the communication.

PCAN Dongle

Snapshot of the CAN messages on the PCAN-VIEW tool

Snapshot of the CAN messages on the Bus Master tool

ECUs

Android and Communication Bridge

Group Members

Design & Implementation

The Android and communication bridge controller is responsible for establishing communication between the car and the Android app using BlueSMiRF RN41 bluetooth module. The Android app sends the check points to the car helping it to make its way to the destination and also receives the data from various modules to be displayed on the app. The data is transferred and recieved from other controllers via CAN bus. The bluetooth module communicates with the SJOne board using UART communication at 115200 bps. The SJOne and bluetooth module connections are as follows:

BLE Block Diagram
Pin Configuration:
Sl. No Pin on SJOne Board Pin on BlueSMiRF RN41 Bluetooth module Purpose
1 TXD2 RXD Transmit using UART2(TXD2) to RN41
2 RXD2 TXD Receive using UART2(RXD2) from RN41
3 3V3 VCC 3.3V voltage supply
4 GND GND Ground

Hardware Design

Bluetooth Modem

Bluetooth Module BleSMiRF Gold Features:

  • v6.15 Firmware
  • FCC Approved Class 1 Bluetooth****Radio Modem
  • Extremely small radio - 0.15x0.6x1.9"
  • Very robust link both in integrity and transmission distance (100m) - no more buffer overruns!
  • Low power consumption : 25mA avg
  • Hardy frequency hopping scheme - operates in harsh RF environments like WiFi, 802.11g, and Zigbee
  • Encrypted connection
  • Frequency: 2.402~2.480 GHz
  • Operating Voltage: 3.3V-6V
  • Serial communications: 2400-115200bps
  • Operating Temperature: -40 ~ +70C
  • Built-in antenna

Software Design and Implementation

The Software design for the app is as follows:

1. The current location of the car is extracted through the GPS of the mobile.

2. As per location, a route is calculated by the app and checkpoints is sent to the BLE module(SJ-one board)

3. The Decoding of the received messages is implemented in 10Hz task.

4. Due to challenges faced to parse data in 10Hz, decision was made to shift parsing of data to 1Hz task.

5. After parsing the data, the checkpoints are then send over the CAN bus to Geo module for processing.

BLE Module Software Implementation


Android App

A bluetooth connection is established between android app and bluetooth module. The android app sends a start bit on UART to the master controller to indicate the start of the app and it acts as the start button for the car. The app starts listening to the incoming data and fetches the current location of the car. The distance is calculated between the start and destination location. The JSON is generated from the google map API from where we fetch the check points to be sent to the geo controller. The app also displays the relevant car information for the user.

Android App Flow Chart

App Screen 1
App Screen 2
App Screen 3
App Screen 4


BLE Controller

The BLE controller initially enables the uart2 and CAN bus to establish communication between the app and other modules on the CAN bus. The car starts with the command from the app which is received in the 10Hz task and is sent to master module to notify other modules on the CAN bus. After generating route on the app, the app sends the check points to the BLE controller which parses the latitude and longitude values and sends it to the Geo module through the CAN bus.

Communication Bridge Flow Chart


Testing & Technical Challenges

While receiving data from android app, it was observed that there was loss of information due to the buffer size and the receive queue size. It was solved by increasing the buffer and queue size and also due to baudrate, decision was made to receive data in 10Hz and use the same in 1 Hz task. Thus, by adjusting the transfer rates the data loss was reduced.

In the android application, bluetooth connectivity was limited to the main activity only and it was difficult to pass it to multiple activities. Therefore, the app was built on only one main activity by processing the data in the background to avoiding crashing. This was done because there are chances of crashing since the UI cannot handle too much on processing.

Due to data loss on the app side, it was decided to take the current location from the app and generate the check points. Therefore, to reduce data loss the data was transmitted and received in a thread.

Geographical Controller

Group Members

Design & Implementation

Geographical Controller is responsible for commanding the Motor Controller on which direction the vehicle has to move. It consists of a Global Positional System (GPS) module to track the current location of the vehicle and a Compass (Magnetometer) to command the direction of steer to the motor with respect to its current direction and Bearing Angle of the GPS.

Basic Geo Block Diagram

We have developed the algorithm based on the following parameters:

1. Bearing Angle

2. Heading Angle

1. Bearing Angle: Bearing Angle is the Angle between two points with respect to the Geographical North. We can calculate this from the GPS module by using Haversine formula. Further details are discussed in the Software Design section.

Bearing Angle

As we can see in the picture, If we consider point A is the current location and point B as the destination, 𝚹 represents the Bearing angle between point A and point B with respect to its Geographical North.

2.Heading Angle: Heading Angle is the angle of the orientation of the vehicle(clockwise) with respect to the Geographical North. The output from the Compass (LSM303) will be from 0 to 360 degrees. However, due to the magnetic declination, the compass needs to be calibrated.

Compass Heading


Hardware Design

The below picture shows the hardware schematic of Geo-Controller.

Hardware Schematic

LSM303DLHC:

LSM303 has both Compass (Magnetometer) and Accelerometer. We have used LSM303 to calculate the compass raw Heading angle. The LSM303 can be used as a compass by calculating the angle of magnetic field with respect to x-axis and y-axis. The communication between SJOne board and LSM303 is done using the I2C serial bus interface. The connections between LSM303 and SJOne board is showed in the following picture.

LSM303

We used continuous conversion operation mode and the I2C interface supports fast mode which is 400KHz. However, we are using the standard mode which is 100 KHz.

Compass-SJOne board Pin Connect

GPS Module:

The GPS module is very critical to the project as it should be very accurate and fast enough to update the location when the vehicle is moving. So, we have used the Ultimate GPS module from Adafruit which updated at a rate of 10Hz that means the GPS updates the geolocation data every 100 milliseconds. The below picture shows the GPS module. The communication between GPS and SJOne board is done via UART.

The default baud rate of GPS module is 9600. However, we can increase the baud rate based on our requirement.

Adafruit Ultimate GPS Module

The pin connect of GPS to SJOne is showed in following picture.

GPS-SJOne Pin Connect

After making proper connections, the GPS will take some time to get the Fix. If the red LED is blinking, we have to understand that the Fix is not available. Sometimes we will not get a fix or it will take more time to get the fix if the board is indoors. From our observations, using a coin battery reduce the fix time in case there is a flakey power connection.

GPS showing No Fix

The output of GPS module will be strings which consists of multiple data formats such as GPGGA, GPGLL, GPRMC, GPGSA etc. In our software, we have parsed the data only for GPGGA raw data as this string contains all the data required to locate the current location. GPGGA refers to Global Positioning System Fix Data. The following snapshot gives the complete description of the GPGGA message format.

GPGGA Format

Software Design

Geo-Controller Flowchart

Flow of Geo Algorithm:

1. Receive System start command from master

2. Check for GPS Fix.

3. If Fix available, send current vehicle geographical coordinates(Latitude and Longitude) to Android via Bluetooth.

4. Android receives the current vehicle location, identifies vehicle destination point along with the checkpoints and sends the checkpoints to Geo Controller via CAN.

5. When fix is available and last checkpoint received from Android, Geo-Controller puts all the received checkpoints into a vector one after the other.

6. Geo-Controller checks whether the destination point is reached. If not, Geo-Controller takes one checkpoint at a time and calculates the compass heading, GPS bearing angle and distance from the starting point to first checkpoint (using Haversine formula).

7. After calculating the heading, bearing angles, Geo-Controller decides on which direction the vehicle should move by using the steering control algorithm and gives the direction command to master.

8. Master controls the motor to move in that direction. Once the vehicle reaches the first checkpoint, the same flow continues for the remaining checkpoints.

9. As soon as the last destination checkpoint is popped, we check for the checkpoint vector size. If the vector size is zero and when the vehicle reaches the destination point, we turn a destination reached flag and commands the master to stop the vehicle.

We can calculate the bearing angle and distance between the source and destination points using the below mentioned Haversine Formulae.

Haversine Formula: 

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

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

                 Distance, d = R x c

                 Where,

                               Φ is latitude

                               λ is longitude

                               R is Earth’s radius i.e., 20,902,231 Feet/6371 Km

                               Δφ = latitude2 – latitude1

                               Δλ = longitude2 – longitude1

Implementation

1. Usage of Vectors: We used vectors to store and process the checkpoints from Android application. The main reason for using vectors is that the size will grow and shrink with every addition and deletion of checkpoints. So, we can simply check the number of checkpoints left from the vector. We also turned a flag when the vector is empty which means when the flag is on, we have reached the destination.

2. Steer Command: Direction command to master is given based on the different ranges mentioned in the below picture:


Deflection = Compass Heading - Bearing Angle

Steer Command Range

Ex: Consider the vehicle is at 90 degrees (Compass heading) with respect to North, and if the angle between the source and destination is 20 degrees with respect to North(Bearing Angle), which direction the vehicle should turn?

A. We know Compass Heading = 90 deg, Bearing Angle = 20 deg. So, the difference is 90 - 20 = 70 deg. deflection, so the vehicle has to turn RIGHT since as per our algorithm, the vehicle has to turn right for 60-180 deg. deflection range(deflection = compass heading - bearing angle).

The offset value and the steer angular range is calibrated after rigorous testing. For example: If the compass heading at 60 degree angle from bearing angle (clockwise), we have checked which direction the vehicle is attaining the optimum smooth movement, Half Left or Left? Based on these factors, the calibration is done for steer range.

3. Dummy Coordinates: We are using the dummy coordinates at the start point and at the end point as delimiters. For example, we are sending (1,1) point initially to check for the first checkpoint. Similarly, we are sending (0,0) at the end after receiving the destination point. We implemented an algorithm to check these conditions and send corresponding commands to the master to inform that the vehicle has reached the destination.

Testing & Technical Challenges

Magnetometer Calibration:

Reason for calibration:

As mentioned in the below picture, the LSM303 compass range is not concentric with actual compass range. There will be a deflection due to this. For example; we have observed the deflection of LSM303 compass is very minimal with respect to ideal compass readings for a range of 90 – 180 degrees. However, the LSM303 deflection increases as the LSM303 compass angle deflection will slowly increases from 180 to 360 and 0 to 90 degrees.

Reason For Calibration

Few observations are mentioned in table below. So, we used linear equations to calibrate by finding the slope and the addition factors. Since, the deflection is not linear, we have divided the range of 0-360 angle in three different ranges and applied the linear equations respectively.

Observed Magnetometer Deflection

Calibration Before Mounting on the Car:

Compass Calibration Before Mounting On Car
Compass Calibration Before Mounting On Car - Actual Vs Observed


However, after mounting the LSM303 compass on the vehicle, the LSM303 compass range from 130 – 220 degrees instead of 90 - 180. So, we have divided the angle into three different ranges i.e., 0 – 185, 185 – 340 and 340 – 360 and applied linear equations as showed below. 


                 Y = a X + b;
                 
                 Where,

                               Y is actual reading

                               X is raw magnetometer readings

                               a is multiplication factor

                               b is additional factor


Calibration After Mounting on the Car:

Compass Calibration After Mounting On Car
Compass Calibration After Mounting On Car - Actual Vs Observed

Sensor and I/O

Group Members

SENSOR

Design & Implementation

We are using Maxbotix LV-EZ Ultrasonic sensors (MB1000). The configuration of the sensor is 3:1 that is three sensors in the front separated by 60 degrees apart and one in the rear. The ultrasonic sensors mounted on the car are used to detect the obstacle on its route. These sensors are connected to the SJOne board and work with a 5.0V power supply. The SJ One board then sends the sensors message with the help of CAN bus.

The pin description of Maxbotix LV-EZ Ultrasonic sensors is as follows:

Pin 1-BW- Unused, leave disconnected or connect to circuit common ground.

Pin 2-PW- Digital Proximity Logic, outputs a High/Low logic voltage level depending on proximity detection. High means an object has been detected in the detection zone. Low means no object is present. There is a ~2.5 second delay on acquiring targets and a ~1.5 second delay for releasing a target once detected. This hysteresis improves sensor reliability.

Pin 3-AN- Unused, leave disconnected or connect to circuit common ground.

Pin 4-RX- This pin is internally pulled high. The LV-ProxSonar-EZ will continually measure proximity information and output send to data. Leave the pin disconnected or hold the pin high for proximity information. Hold low to stop all sensor activity and reset acquire timers. Upon returning to a high state, the sensor will initiate a calibration sequence.

Pin 5-TX- The TX output delivers asynchronous serial with an RS232 format, except voltages are 0-Vcc

Pin 6-+5V- Vcc – Operates on 2.5V - 5.5V. Recommended current capability of 3mA for 5V, and 2mA for 3V.

Pin 7-GND- Return for the DC power supply. GND (& Vcc) must be ripple and noise free for best operation.

Hardware Design

The ultrasonic sensor is interfaced through GPIO, each sensor requires 2 pins, PW and RX, in addition to the two pins required for powering up the sensor. The PW pins for each sensor is configured as an interrupt. The following table and figure shows the pin connections for all the sensors to the SJOne board.

Sensor Schematic


Sr.No SJOne Pin Number Sensor Pin Function
1 P1.23 Middle Sensor PW
2 P 2.3 Middle Sensor Rx
3 P 1.28 Left Sensor PW
4 P 2.5 Left Sensor Rx
5 P1.22 Right Sensor PW
6 P 1.29 Rear Sensor Pw
7 P 2.7 Rear Sensor Rx


The figure below shows the design for the 3D mount for the front sensors.

  • Ultrasonic mount Design

  • 3D design


Ultrasonic Sensor

There are three ultrasonic sensors for the front of the car positioned at different angles to provide a wide ultrasonic "vision" for the car. The mount for the sensors was 3D printed such that we have the flexibility to change the angle of the sensor at a later stage when debugging the sensor.

Hardware Interface

In this section, you can describe how your hardware communicates, such as which BUSes used. You can discuss your driver implementation here, such that the Software Design section is isolated to talk about high level workings rather than inner working of your project.

Software Design and Implementation

The readings from the sensor is taken in the form of PWM signals with the help of interrupts. The following steps were performed to take readings and calculating distance from the sensor

  1. Configure the PW pin of sensor as input.
  2. Configure RX pin of the sensor as output and set it high.
  3. Enable the Rising and the Falling edge interrupt on the PW pin of the sensor.
  4. Start timer at the rising edge of the interrupt (time T1).
  5. At falling Edge of the interrupt stop the timer (time T2).
  6. The distance of the obstacle is = (T2-T1)/147 inches.
  7. Check for threshold distance. If distance > threshold distance for given sensor, then convey to master that obstacle was found.
  8. If middle sensor value has distance <= critical distance then convey then set critical bit, conveying that car must stop to avoid a collision
  9. Broadcast data on CAN bus.


Sensor Flowchart

I/O

Design & Implementation

The IO section for the car consists of two main components, an LCD screen and LED indicators.

LCD Schematic
LED Schematic


















IO is integral to troubleshooting the working of the car. The team first decided upon the various important indicators that would be needed to troubleshoot the working of the car and then decided to translate them into either LED indicators or LCD screen elements. The table below summarizes the features for IO and which IO element was used to represent them on the car.

Sr.No Sensor Pin Function LCD Element LED Element Present
1 System Command (Start, Stop Resume) An on screen LED that turns off/on for each command Yes
2 Right Turn An on screen LED that turns off/on Yes
3 Left Turn An on screen LED that turns off/on Yes
4 Brake An on screen LED that turns off/on Yes
5 Forward An on screen LED that turns off/on Yes
6 Reverse An on screen LED that turns off/on Yes
7 Right Sensor Gauge No
8 Left Sensor Gauge No
9 Middle Sensor Gauge No
10 Rear Sensor An on screen LED that turns off/on Yes
11 System Status (Heatbeat) Gauge No
12 Speed. Meter. No
13 Battery Indicator Gauge No

Hardware Interface

The hardware interface for the LCD is through UART for LED it is through GPIO. LCD Hardware interface: The LCD controller works on UART communication. Uart-2 on SJONE board is used for sending the data and command to uLCD-32PTU. 

We are using uLCD-32PTU to debug and display the important CAN message.  We used this LCD because of following features:
  • The uLCD-32PTU is a compact and cost effective Intelligent Display Module packed with plenty of features capable of being an interface controller for a number of applications.
  • Built in extensive 4DGL graphics and system library functions.
  • Simple UART communication at 9600 Baud rate is used to communicate with SJONE board.

LED hardware interface: For the LEDs we connected the the positive end to the VCC and the negative end to the GPIO. This was done to prevent the SJOne port from being the current source for a constantly glowing LED. There are 10 LEDs in total on the car. 4 in the front and 6 in the rear.

  • uLCD32PTU Connections
  • uLCD32PTU Rearview
  • uLCD32PTU Frontview
  • uLCD32PTU Programming Adapter


Software Design

LCD screen changes

  • Form 0

  • Form 1

  • Form 2

  • Form 3

  • Form0: This is the home screen for Spartan and Furious which displays the logo of our team. This screen is displayed when there is no system command from the Master. As soon as the IO receives the master system command the IO displays all the relevant data using periodic callback function.
  • Form1: This is the screen which is being displayed after the home screen. This screen shows the sensor data, Speed indication, System command status and the direction in which the car is moving.. There are four different gauges for different sensor Data. Each gauge indicates obstacle proximity detected from ultrasonic sensors which are placed on left (L), centre (M), right (R) and rear sensor at back (B) of the car. The direction of the car is indicated using different LEDs for Front(F), Right(R), Left(L), Back(B) indication. The system command LED indicates that master is in sync with all the modules.
  • Form2: In this screen IO displays the System Status of all the modules and also the System status given by the master module to all the modules. System status consists of start, stop and Resume status. There are six different LED’s indication the Heartbeat of the modules. There is a battery indicator Gauge which displays the battery life.
  • Form3: This is the ‘Geo Status’ screen which shows different parameters such as GPS longitude and latitude, current compass direction and different modes of car.

The data is sent to the LCD in specified format. For sending Gauge, LED, Speedometer data we need to send five bytes of data.
Byte1 - Event byte
Byte2 - Object type
Byte3 - Object number
Byte4 - Data byte 1
Byte5 - Check sum

For angular meter readings we have six bytes of data to be sent.
Byte1 - Event byte
Byte2 - Object type
Byte3 - Object number
Byte4 - Data byte 1
Byte5 - Data byte 2
Byte6 - Check sum

For String to be passed we need to have 3 bytes + each character as data byte + checksum byte.
Byte1 - Event byte
Byte2 - Object type
Byte3 - Object number
Byte4 - Data byte 1
Byte5 - Data byte 2
Byte6 - Data byte 3
.
.
.
Byte n+3 - Data byte n
Byte n+4 - Check sum
 The data is sent to the LCD using UART. Following steps should be performed in order to display the readings on LCD.

  1. Wait for system command from master.
  2. Once master command has been received, collect CAN data for all information that has to be shown on IO.
  3. Update the corresponding LCD element, and toggle the LEDs based on data received.
  4. Switch LCD form every 5 seconds.
  5. If destination reached, show the destination reached form.


  • LCD code Flowchart

  • LED code Flowchart


Testing & Technical Challenges

Sensor Technical Challenges and Testing:

We have used sensor in PW mode. In this mode the major challenge was triggering of the sensor. We had to trigger four sensors in such a way that they do not interfere with each other. In order to tackle this issue we triggered front and rear sensor at same time and after a small delay we triggered right and left sensor at same time. The second major challenge is sensor reflection from ground and sensor mounting design. We had to mount the sensor with an angle of 20 degrees with the horizontal. Still there were some reflections but they were minimal. We designed 3D print for sensor mounting such that the angle between each sensor was exactly 60 degrees. The beam angle of sensor is 30 degrees in each side.


IO Technical challenges:

LCD mounting was the main challenge for IO. We were using LCD and LED for debugging purposes. For LED we connected same GPIO pins for front and back signal pins. So, the issue came with different colour LED’s. The LED which has less resistance draws all the power and only that LED was turning ON and OFF. The other LED was not showing any indication. We had to change both LED’s with same color and then it was working fine. The second issue was of common ground for LCD. We were sending data using UART and had given a Ground pin connection to LCD from the power source. There was no change in the LCD screens and then we figured out that it was due to no common ground connection.

Motor Controller

Group Members

Design & Implementation

The motor controller is responsible for generating the driving and steering action of the car. For this purpose, we have two types motors viz DC motor for driving and Servo motor which is used for changing directions of the car. The motor controller is also interfaced with a speed encoder for generating a feedback mechanism to automatically control and monitor the speed of the car. Our car came equipped with a Servo motor and brushed DC motor which is connected Electronic Speed Control (ESC).

Hardware Design

Motor Hardware Schematics
SJOne Pin Diagram
Sr.No Pin Number Pin Function
1 P0.0 CAN RX
2 P0.1 CAN TX
3 P2.0 Servo motor
4 P2.1 DC motor
5 P2.5 Speed Encoder



  • Hardware Specifications
DC Motor
1. DC Motor

Our car came with Titan 12T 550 brushed motor and waterproof ESC. The ESC drives the DC motor based on the Pulse Width modulation (PWM) applied to it. The power supply required for this motor is 8.4 V. Maximum speed of upto 30mph can be achieved. The rotational speed is proportional to the EMF generated in its coil and the torque is proportional to the current.The main connection pins driving the motor are VCC,GND and the Control pin (PWM). The pin P2.1 of SJ-one board is connected to supply the required PWM to the motor. The basic working principle of DC motor is illustrated in the following figure : Since the preprogrammed controller has to be replaced by using our design ,the DC motor is then tested with Digital Oscilloscope for getting the frequency of operation and equivalent PWM values for full throttle condition in the forward as well as backward condition. It was observed from the waveform that the frequency of operation is 100Hz. The range of operational duty cycle is 10% to 20% with 15% being the neutral value or the stop condition. In order to accelerate the car a PWM value in the range of 15.6%-20.0% is applied. The 15.6 is the minimum pickup PWM that should be supplied in order to get the car moving at full load.

Servo Motor
2. Servo Motor

The servomotor used in the car is #2056 a waterproof all weather-action and double the steering power as compared to standard servos. The servo motor is responsible for controlling the steering action of right or left by applying a suitable PWM pulse. The servo motor can be driven with 3.3 V power supply. The pin P2.0 of SJ-one board is connected to supply the required PWM to the motor. After testing the servo motor, we found that the frequency of operation is 100Hz and the operational duty cycle range is 10.0%-20.0% with 15% being the neutral value. For a full right deflection, we provide input PWM pulse ranging from 15.0-20.0% and for full deflection to the left we apply 10.0-15.0% of PWM.





Digital Oscilloscope readings for the motors

Hall-Effect Principle.
3. Speed Sensor

The speed feedback is monitored through the speed encoder which works on the Hall-effect principle. The Hall-effect speed sensor works as a transducer whose output voltage varies in response to the magnetic field. The sensor is mounted on the Spur gear instead of the wheel. The sensor would detect the rotation of axle. The motor controller would detect whenever the magnet is aligned with the sensor. This would generate a pulse. The pulse is detected in the form of rising-edge interrupt. This gives the wheel rotation count. The wheel rotates for every 1/4th rotation of the spur gear. The rotation count can then be converted to rpm to calculate the speed of the car.







Hardware Interface

The CAN bus is used to send and receive messages to and from the Master Controller. The motor controller receives driving and steering signals from the master. The speed calculation is performed using the speed sensor and is sent on the bus, which will be received by the IO controller for display purposes.

Software Design

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

Flowchart.
Speed Feedback Implementation.

Implementation

The motor controller receives all its signals from Master controller from the CAN bus. The motor controller receives the steer and drive command from the master. The motor controller receives the System start command which boots and decodes further drive signals to the motor controller. Upon receiving the drive command the motor controller decodes the steering action. Upon receiving suitable data about the obstacle from sensor controller the master controller relays appropriate steering action. To achieve better performance in steering, the turn is categorized as FULL and HALF. This gives better precision in turning.

  • Speed Regulation:

Upon detection of uphill the pulse received from the speed encoder reduces. This is detected and the motor feedback is designed such that the speed is increased by providing higher value of PWM value to drive the DC motor. Similarly, for downhill the pulse count received increases which is detected by the speed encoder and the speed is reduced by applying reduced PWM.

Testing & Technical Challenges

  • Wheel Alignment Error

Though the neutral value of PWM is 15% at which the servo is supposed to be aligned straight. In practice, however when we tested the car for straight run slight deflection towards right was observed when the PWM pulse width was set to 15.0 %. Thus, to correct this, we provided correction value of -0.98 giving a resultant PWM pulse width of 14.02%. Thus, we fixed the wheel alignment and obtained the desired straight path traversal.

  • Speed Sensor Assembly

The speed encoder was assembled on the spur gear of the car. The installation at first was such that outer fitting was large and was avoiding the pulse trigger by the magnet.As a result of which we were unable to modulate speed.Issue was resolved by using the correct outer assembly of the gear which generated the speed feedback.

Master Controller

Group Members

Introduction and Responsibilities

Master controller is the brain of the car.
All the decisions are taken by the master module. Some of the major responsibilities of the master module are:

  • System command (Initial Start) : Upon successful connection with Android app, master command will send as system start command to all the other modules on the CAN bus. This command advises all the modules to start their processing(similar to wake up).
  • Obstacle avoidance : Based on the sensor values, master will decide the direction to be taken by the motor.
  • GPS data: Depending upon the GPS calculated direction and obstacle data received from sensor module, master controller will decide the steer and drive of the motor.
  • Determine if all the modules on the bus are active or inactive.

The master controller using the data from other modules, drives the car safely to the destination.

Hardware Design

  • Interface of CAN Bus with six SJ-One controller boards on PCB was designed.
  • Ribbon Cables were used instead of individual jumper wires to assist in designing less complex circuit.


Interface with the CAN Hardware

Software Design

Master Controller needs to periodically receive and transmit updated data from all the modules in order to make an efficient decision. Based on the priority of the data, corresponding CAN messages are parsed in 100Hz, 10Hz or 1Hz periodic scheduler tasks respectively. Data received can be viewed and traced in real time using PCAN View or BUS Master tool.

Software Implementation

The diagram below details out the flow of data to and from the Master Controller.

Master Controller Execution Flow

Heartbeat

Master Controller is responsible to identify if all the modules are active or inactive. All the modules send the heartbeat messages on the CAN Bus every 1Hz. If the heartbeat message is not received from any module, master marks the system status of the module as inactive. The system status message is update at run time on the I/O and the app. User can then reset the inactive module.

The code snippet for the receiving heartbeat messages and determining system status is as follows: 

if(dbc_decode_BLE_HEARTBEAT(&ble_heartbeat_cmd, can_msg.data.bytes, &can_msg_hdr))
   system_status_message.MASTER_SYSTEM_STATUS_ble = 1;
if(dbc_decode_SENSOR_HEARTBEAT(&sensor_heartbeat_cmd, can_msg.data.bytes, &can_msg_hdr))
   system_status_message.MASTER_SYSTEM_STATUS_sensor = 1;
if(dbc_decode_GEO_HEARTBEAT(&geo_heartbeat_cmd, can_msg.data.bytes, &can_msg_hdr))
   system_status_message.MASTER_SYSTEM_STATUS_geo = 1;
if(dbc_decode_IO_HEARTBEAT(&io_heartbeat_cmd, can_msg.data.bytes, &can_msg_hdr))
   system_status_message.MASTER_SYSTEM_STATUS_io = 1;
if(dbc_decode_MOTOR_HEARTBEAT(&motor_heartbeat_cmd, can_msg.data.bytes, &can_msg_hdr))
   system_status_message.MASTER_SYSTEM_STATUS_motor = 1;


To determine the direction and throttle of the car, master controller needs the data from sensor and Geo module. These data are critical for the system and are parsed in 10Hz periodic tasks. After the master receives BLE_CMD = START, master will send SYSTEM_CMD= START command to all of the modules, which notifies them that the Bluetooth communication via app has been initiated. The car is capable of reaching a destination or just running while avoiding obstacles with no destination set. The software design of the master controller supports two modes for the car:

Free Run mode

  • For switching to free run mode, the “FREE RUN” button needs to be selected from the app.
  • As per the sensor data, the movement of the car is decided by the master controller.
  • By default the motor is commanded to move straight.
  • If there is an obstacle in the middle sensor, then the sensor data for left and right sensor is checked.
  • If there is an obstacle at a very short distance, critical obstacle bit is set and car is first stop.
  • When the car needs to stop due to obstacles, reverse sensor value is checked.
  • The car stops only when there are obstacles in all directions or user sends Stop from the app.
  • The following table depicts the motor command sent by master to the motor controller as per the sensor values.
Sr no Left sensor value Middle sensor value Right sensor value Critical value Rear sensor value Motor Command
0 0 0 0 0 X STRAIGHT
1 0 0 1 0 X HALF RIGHT
2 0 1 0 0 X LEFT
3 0 1 1 0 X RIGHT
4 1 0 0 0 X HALF LEFT
5 1 0 1 0 X STRAIGHT
6 1 1 0 0 X LEFT
7 1 1 1 0 0 REVERSE
8 1 1 1 0 1 STOP
9 X X X 1 0 REVERSE
10 X X X 1 1 STOP
  • When STOP button is selected from the app,the BLE will advise the same to master controller and master will send SYSTEM_CMD= STOP to all the modules. This stop command notifies them that the Bluetooth communication via app has been deactivated.


Free Run Mode Flow Chart

Navigation mode

  • For switching to navigation mode, the “NAVIGATION MODE” button needs to be selected from the app.
  • In this mode, Geo module sends the desired direction to the master controller.
  • The master controller will check if there is any obstacle in the desired path.
  • In case of obstacle, car moves as per the obstacle avoidance algorithm (free run mode).
  • Once Destination Reached signal is received from the Geo module, the car stops.


Navigation Mode Flow Chart

Common Technical Challenges

Issue 1

One of the most unexpected issue faced during testing, was we were unable to receive data from motor and sensor module during testing for demo1. After debugging, we realized that the ribbon cable we purchased was meant for a special purpose and was shorted internally as shown in the picture because of which we were unable to receive data from the CAN bus.


Ribbon Breakout
Ribbon Cable

Conclusion

This project has helped each one of us grow, not just academically, but professionally as well. This project did achieve the goals it promised, these were:

  • CAN: Teaching us to work with the CAN bus and protocol; a simple, robust and noise immune mode of communication and using DBC files as a method of managing CAN messages.
  • GIT: Using GIT as a method of continuous integration and improve productivity. GIT allowed us to work independent of our schedules, boosting our productivity beyond the time the team members met.
  • Team Work: Working in a fairly large group gave us a real sense of team work and collaboration.
  • Professionalism and accountability.

On testing the car we found a lot of practical hurdles that we had to overcome. Debugging issues was a large part of our efforts to improve the working of our car. To mention a few:

  • Hardware issues:
    • Ribbon Cable: Issues with ribbon cables, we found the hard way that the ribbon cable we initially used was for a specific purpose making it incompatible with our boards.
    • Voltage fluctuation disrupting the CAN bus: Inconsistent soldering on on of the power rails, caused the CAN bus to fail altogether.
  • Bluetooth bridge: Maintaining a Bluetooth connection between different activities in the app was a problem.
  • Sensor: A section of code was rearranged to solve a problem that prevented the sensor from sending messages to the CAN bus.
  • I/O: The I/O module is receiving a large amount of data, causing a task overrun. This was fixed by re-prioritizing the display and rearranging the code.

To the teams that are designing their car:

  • Use a faster sensor and apply filters like a median or Gaussian filter to improve sensor performance.
  • Ensure hardware connections are tested thoroughly.
  • Start with the implementation for the Geo module early.
  • Ensure that your Android App can communicate consistently with SJOne board.

Project Videos

CMPE243_F16_Spartan_and_Furious Demo Day Video

Project Source Code

References

Acknowledgement

We would like to acknowledge the following people for their help in completing this project:

  • Preet for his invaluable teachings.
  • The ISAs for their great advice and tips.
  • Siddarth for helping with the design for our 3D mount.
  • Maxbotix for a generous student discount on their product.
  • Microchip for the free CAN ICs.
  • Cratus Technologies for letting us use their 3D printer.

References Used

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