Difference between revisions of "F14: Team3-Self Driving Car - Optimus Prime"

From Embedded Systems Learning Academy
Jump to: navigation, search
(→‎Implementation)
(→‎Parts List & Cost)
 
(297 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
=== Grading Criteria ===
+
== '''Optimus Prime''': The Self-driving Car ==
−
<font color="green">
+
[[File:End_product.jpg|right|thumb|Optimus Prime]]
−
*  How well is Software & Hardware Design described?
+
Optimus Prime, the self-driving car is an autonomous driving vehicle which is capable of driving itself to its destination using GPS. While it does so, it also avoids obstacles using multiple sensors attached to it. It has an LCD screen to display the useful information about the car in real time e.g. distance to the destination, speed, vehicle battery status, etc. The car can be controlled using an android app. This app was designed and developed specifically for this project. Using this app one can start and stop the car, increase or decrease the speed and set a destination to drive up to. This report is about designing and building this self governing car. This documentation is done keeping in mind the students who want to build their own self-driving car and for the curious ones who just want to know what goes inside an autonomous driving vehicle.
−
* How well can this report be used to reproduce this project?
 
−
*  Code Quality
 
−
*  Overall Report Quality:
 
−
**  Software Block Diagrams
 
−
**  Hardware Block Diagrams
 
−
**:  Schematic Quality
 
−
**  Quality of technical challenges and solutions adopted.
 
−
</font>
 
  
−
== Optimus Prime: The Self-driving Car ==
+
== '''Abstract''' ==
−
This project report is about designing and building a self governing car, capable of sensing its environment and navigating without human input. The car senses its surroundings and is capable of updating their maps based on sensory input, allowing the vehicle to keep track of its position.
+
A self-driving car comprises of several controllers, each with a specific task dedicated to it. Our car consists of 6 such controllers. We have named them as Master, Motor, Sensor, GPS, Communication Bridge and I/O controllers. They communicate with each other over the CAN bus as shown in the diagram below. Each controller sends out the information over the CAN bus in the form of messages. Every controller receives only the required messages and performs the necessary task. The path navigation is achieved by the GPS. Thus the controllers do the task of a driver and navigate the path by avoiding the obstacles.The overall block diagram of the project is shown below. It includes all six controllers with their sensors  and actuators, communicating through a CAN bus.
−
 
 
−
== Abstract ==
 
−
This project is about developing a self driven car. It consists of 6 controllers - Master, Motor, Sensor, GPS, Communication Bridge and I/O, which communicate with each other over the CAN bus as shown below. Each controller sends out the information over the CAN bus in the form of messages. Every controller receives only the required messages and performs the necessary task. The path navigation is achieved by the GPS. Thus the controllers do the task of a driver and navigate the path by avoiding the obstacles.
 
  
 
{|
 
{|
Line 21: Line 10:
 
|}
 
|}
  
−
== Parts List & Cost ==
+
==== Parts List & Cost ====
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
Line 92: Line 81:
 
| NHD-0216B3Z-FL-GBW-V3-ND
 
| NHD-0216B3Z-FL-GBW-V3-ND
 
| 1
 
| 1
−
| $$$.$$
+
| $27.00
 
|-
 
|-
 
! scope="row"| 10
 
! scope="row"| 10
Line 100: Line 89:
 
| 1
 
| 1
 
| $6.91
 
| $6.91
 +
|-
 +
! scope="row"| 11
 +
| Bluetooth Bee
 +
| Amazon.com
 +
| B005GI4HFA
 +
| 1
 +
| $23.00
 +
|-
 +
! scope="row"| 12
 +
| Sensor RPM Long
 +
| Sheldon's Hobbies
 +
| Traxxas #6520
 +
| 1
 +
| $11.99
 +
|-
 +
! scope="row"| 13
 +
| Wire retainers/Gear Cover
 +
| Sheldon's Hobbies
 +
| Traxxas #6537
 +
| 1
 +
| $2.99
 +
|-
 +
! scope="row"| 14
 +
| Telemetry Trigger Magnet & Hold
 +
| Sheldon's Hobbies
 +
| Traxxas #6538
 +
| 1
 +
| $2.99
 +
|-
 +
! scope="row"| 15
 +
| Front Bumper & Screws
 +
| Sheldon's Hobbies
 +
| TRA2542
 +
| 1
 +
| $9.94
 
|-
 
|-
 
! scope="row"|  
 
! scope="row"|  
Line 106: Line 130:
 
|  
 
|  
 
|
 
|
−
| $$$.$$
+
| 849.13
 
|-
 
|-
 
|}
 
|}
  
−
== Introduction ==
+
==== Team Schedule ====
−
=== CAN Bus: A brief introduction ===
 
−
=== The Six Controllers ===
 
−
* [[Master Controller]]
 
−
* [[Motor Controller]]
 
−
* [[Sensor Controller]]
 
−
* [[Geographical Controller]]
 
−
* [[Android & Communication Bridge Controller]]
 
−
* [[I/O Unit Controller]]
 
−
== Design & Implementation ==
 
−
=== Controller Communication Table ===
 
−
 
 
 
{| class="wikitable"
 
{| class="wikitable"
−
|+ Controllers
 
 
|-
 
|-
−
| Controller ID
+
! scope="col"| Sl.No
−
| Controller Type
+
! scope="col"| Start Date
 +
! scope="col"| End Date
 +
! scope="col"| Task
 +
! scope="col"| Status
 +
! scope="col"| Actual Completion Date
 
|-
 
|-
−
| 0x01
+
! scope="row"| 1
−
| Master Controller
+
| 09/15/2014
 +
| 09/16/2014
 +
| Order RC Car
 +
| Completed on time
 +
| 09/20/2014
 
|-
 
|-
−
| 0x02
+
! scope="row"| 2
−
| Motor Controller
+
| 09/15/2014
 +
| 09/16/2014
 +
| Order Other parts(Sensor/LCD/Motor Controller...)
 +
| Completed
 +
| 09/20/2014
 
|-
 
|-
−
| 0x03
+
! scope="row"| 3
−
| Sensor Controller
+
| 9/30/2014
 +
| 11/25/2014
 +
| Master Controller Team task
 +
| Completed
 +
| 12/18/2014
 
|-
 
|-
−
| 0x04
+
! scope="row"| 4
−
| Geographical Controller
+
| 10/06/2014
 +
| 11/15/2014
 +
| Sensor Team task
 +
| Completed
 +
| 11/15/2014
 
|-
 
|-
−
| 0x05
+
! scope="row"| 5
−
| IO Controller
+
| 9/30/2014
 +
| 10/20/2014
 +
| Motor Controller Team task
 +
| Completed
 +
| 11/25/2014
 
|-
 
|-
−
| 0x06
+
! scope="row"| 6
−
| Bridge Controller
+
| 10/4/2014
−
|}
+
| 10/30/2014
−
 
+
| Geographical Controller Team task
−
{| class="wikitable"
+
| Completed
−
|+ Common Communication Table
+
| 12/18/2014
 
|-
 
|-
−
| Message Number
+
! scope="row"| 7
−
| Purpose / Data layout
+
| 10/7/2014
 +
| 10/30/2014
 +
| I/O Team task
 +
| Completed
 +
| 11/25/2014
 
|-
 
|-
−
| 0x101
+
! scope="row"| 8
−
| Get version and boot info
+
| 9/30/2014
 +
| 11/30/2014
 +
| Communication Bridge + Android Team task
 +
| Completed
 +
| 11/30/2014
 
|-
 
|-
−
| 0x102
+
! scope="row"| 9
−
| Get general info
+
| 10/30/2014
 +
| 11/01/2014
 +
| Complete project integration
 +
| Completed
 +
| 11/30/2014
 
|-
 
|-
−
| 0x103
+
! scope="row"| 10
−
| Synchronize (set) time:
+
| 11/30/2014
−
byte [0-3] : System time
+
| 12/10/2014
 +
| Testing Phase-1
 +
| Completed
 +
| 12/10/2014
 
|-
 
|-
−
| 0x201
+
! scope="row"| 11
−
|  
+
| 12/11/2014
−
byte [0-3] : Version Info
+
| 12/14/2014
−
byte [4-7] : boot timestamp
+
| Testing Phase-2
−
|-
+
| Completed
−
| 0x202
+
| 12/14/2014
−
|  
 
−
byte [0-3] : Current time
 
−
byte [4]  : CPU usage %
 
 
|}
 
|}
 +
 +
== '''Introduction''' ==
 +
==== CAN Bus: A brief introduction ====
 +
Controller Area Network is a serial communication bus which allows microcontrollers to communicate with each other within a vehicle without a host computer. It uses differential transmission on a twisted pair wire which results in high immunity to electrical interference. Each microcontroller works as a node. There are several nodes that are connected to each other through a CAN bus. Each node is able to send and receive messages, but not simultaneously. There is an arbitration scheme which works on message priority. Each microcontroller has its own message ID. Lower message ID represents higher message priority. To learn more about CAN bus communication, visit the following wikipage article.
 +
* [[CAN BUS Tutorial]]
 +
 +
==== The Six Controllers ====
 +
* [[#Master Controller|''Master Controller'']]
 +
* [[#Motor Controller|''Motor Controller'']]
 +
* [[#Sensor Controller|''Sensor Controller'']]
 +
* [[#Geographical Controller|''Geographical Controller'']]
 +
* [[#Android & Communication Bridge Controller|''Android & Communication Bridge Controller'']]
 +
* [[#I/O Unit Controller|''I/O Unit Controller'']]
 +
 +
== '''Design & Implementation''' ==
 +
==== Controller Communication Table ====
  
 
{| class="wikitable"
 
{| class="wikitable"
−
|+ Subscription Rate Info
+
|+ Controllers
 
|-
 
|-
−
| Byte 0
+
| Controller ID
−
| Effect
+
| Controller Type
 
|-
 
|-
−
| 0
+
| 0x01
−
| Off
+
| Master Controller
 
|-
 
|-
−
| 1
+
| 0x02
−
| 1Hz
+
| Motor Controller
 
|-
 
|-
−
| 5
+
| 0x03
−
| 5Hz
+
| Sensor Controller
 
|-
 
|-
−
| 10
+
| 0x04
−
| 10Hz
+
| Geographical Controller
 
|-
 
|-
−
| 20
+
| 0x05
−
| 20Hz
+
| IO Controller
 
|-
 
|-
−
| 50
+
| 0x06
−
| 50Hz
+
| Bridge Controller
−
|-
 
−
| Any other value
 
−
| Invalid date rate
 
 
|}
 
|}
−
 
−
== [[Master Controller]] ==
 
−
 
−
Group Members:
 
−
'''''Bhargava Leepeng Chandra'''''
 
−
'''''Shashank Tupkar'''''
 
−
'''''Preeti Benake'''''
 
−
 
−
'''Master Controller Team Schedule'''
 
  
 
{| class="wikitable"
 
{| class="wikitable"
 +
|+ Common Communication Table
 
|-
 
|-
−
! scope="col"| Week No.
+
| Message Number
−
! scope="col"| Start Date
+
| Purpose / Data layout
−
! scope="col"| Planned End Date
+
|-
−
! scope="col"| Task
+
| 0x101
−
! scope="col"| Status
+
| Get version and boot info
−
! scope="col"| Actual End Date
+
|-
 +
| 0x102
 +
| Get general info
 +
|-
 +
| 0x103
 +
| Synchronize (set) time:
 +
byte [0-3] : System time
 
|-
 
|-
−
! scope="row"| 1
+
| 0x201
−
| 9/30/2014
 
−
| 10/7/2014
 
 
|  
 
|  
−
  * Implement Basic CAN Hardware to communicate between 2 Controllers
+
  byte [0-3] : Version Info
 +
byte [4-7] : boot timestamp
 +
|-
 +
| 0x202
 
|  
 
|  
−
* Completed
+
byte [0-3] : Current time
−
: We are able to send a message from Tx over CAN and perform a specific operation at the Rx.
+
byte [4]  : CPU usage %
−
| 10/7/2014
+
|}
 +
 
 +
{| class="wikitable"
 +
|+ Subscription Rate Info
 +
|-
 +
| Byte 0
 +
| Effect
 
|-
 
|-
−
! scope="row"| 2
+
| 0
−
| 10/7/2014
+
| Off
−
| 10/14/2014
 
−
|
 
−
* Design CAN Acceptance Filter among different Controllers
 
−
* Define and Implement CAN Frame structure for proper communication
 
−
  establishment
 
−
|
 
−
* Completed
 
−
: Only messages with in range of acceptance filter are received, Decided on CAN frame structure using 11-bit frame.
 
−
| 10/11/2014
 
 
|-
 
|-
−
! scope="row"| 3
+
| 1
−
| 10/14/2014
+
| 1Hz
−
| 10/21/2014
+
|-
−
|
+
| 5
−
* Develop Inter-Controller Communication over CAN
+
| 5Hz
−
* Test point-to-point and Broadcast message transmission
 
−
* Implement a Counter to count and display number of messages
 
−
|  
 
−
* Completed
 
−
: CAN Communication among multiple boards achieved, Point-to-Point & Broadcast modes are working, Able to display the count on 7-Seg Display on SJOne board.
 
−
| 10/19/2014
 
 
|-
 
|-
−
! scope="row"| 4
+
| 10
−
| 10/21/2014
+
| 10Hz
−
| 10/28/2014
 
−
|
 
−
* Layout blueprint for Controller and Module positioning
 
−
* Assemble the RC Car with all the controllers and Modules
 
−
* Define the Message List by working with other teams
 
−
* Start working on CAN Periodic message structure
 
−
|
 
−
* Completed
 
−
: RC car design and module assembly is completed. Need some fine tuning for connections. Message list is generated and periodic message implementation started.
 
−
| 10/28/2014
 
 
|-
 
|-
−
! scope="row"| 5
+
| 20
−
| 10/28/2014
+
| 20Hz
−
| 11/04/2014
+
|-
−
|
+
| 50
−
* Complete CAN Periodic message structure to transmit Broadcast
+
| 50Hz
−
  messages over CAN and establish controlled communication among
 
−
  different controllers
 
−
* Implement Start condition detection and Fetch boot status from
 
−
  all controllers and display the status of each controller
 
−
|
 
−
* Completed
 
−
: Periodic Message Setup done. Able to receive boot status. Need to work on display of status.
 
−
| 11/03/2014
 
 
|-
 
|-
−
! scope="row"| 6
+
| Any other value
−
| 11/04/2014
+
| Invalid date rate
−
| 11/11/2014
+
|}
−
|  
+
 
−
  * Design 'Kill Switch' in co-ordination with Motor Controller team
+
== '''Master Controller''' ==
−
  and Bridge Controller team
+
 
−
* Develop a 'CAN Bus Crash' detection and reset CAN Bus methodology
+
==== Group Members ====
−
* Design Automatic Head Light turn ON/OFF functionality by
+
'''''Bhargava Leepeng Chandra'''''
−
  working with Sensors Controller team
+
'''''Preeti Benake'''''
 +
 
 +
==== Description ====
 +
 
 +
Master controller acts as the 'Brain' of the car. It communicates with all the other Controllers on board to implement different Functions. Being the Brain it intelligently processes the data it receives from Sensor, GPS and Bridge controllers to make the car run autonomously. It has several features embedded in it, and controls the car by sending commands to the Motor Controller. In short the master controller actively Receives, Processes and Transmits real-time data.
 +
 
 +
==== Master Controller Team Schedule ====
 +
 
 +
{| class="wikitable"
 +
|-
 +
! scope="col"| Week No.
 +
! scope="col"| Start Date
 +
! scope="col"| Planned End Date
 +
! scope="col"| Task
 +
! scope="col"| Status
 +
! scope="col"| Actual End Date
 +
|-
 +
! scope="row"| 1
 +
| 9/30/2014
 +
| 10/7/2014
 +
|  
 +
  * Implement Basic CAN Hardware to communicate between 2 Controllers
 
|  
 
|  
 
* Completed
 
* Completed
−
: Kill Switch implemented through Bridge controller. Head Lights implemented. LCD display of Status achieved.
+
: We are able to send a message from Tx over CAN and perform a specific operation at the Rx.
−
| 11/11/2014
+
| 10/7/2014
 
|-
 
|-
−
! scope="row"| 7
+
! scope="row"| 2
−
| 11/11/2014
+
| 10/7/2014
−
| 11/18/2014
+
| 10/14/2014
 
|  
 
|  
−
  * Implement File Log saving to SD Card at periodic intervals
+
  * Design CAN Acceptance Filter among different Controllers
−
  * Work on Restoring to last known Status if the system crashes while running
+
  * Define and Implement CAN Frame structure for proper communication
−
* Develop Detection technique if controllers are reaching 'Error State'
+
  establishment
 
|  
 
|  
 
* Completed
 
* Completed
−
: File Log implemented. Error State is partially implemented. Obstacle detection achieved. Needed refinement in Direction control logic. Need to implement reverse logic.
+
: Only messages with in range of acceptance filter are received, Decided on CAN frame structure using 11-bit frame.
−
| 11/18/2014
+
| 10/11/2014
 
|-
 
|-
−
! scope="row"| 8
+
! scope="row"| 3
−
| 11/18/2014
+
| 10/14/2014
−
| 11/25/2014
+
| 10/21/2014
 
|  
 
|  
−
  * Project Integration and testing Basic Self_Drive Capability of the Car
+
  * Develop Inter-Controller Communication over CAN
−
  * Check the Functionality and behavior of all controllers in all the known
+
  * Test point-to-point and Broadcast message transmission
−
  contexts
+
  * Implement a Counter to count and display number of messages
−
  * Perform modifications (if any) to eliminate any bugs to make the car work
 
−
  seamlessly
 
−
* Final Integration of car and testing there after
 
−
 
 
 
|  
 
|  
 
* Completed
 
* Completed
−
: Integration Started. Faced difficulty in synchronization.  
+
: CAN Communication among multiple boards achieved, Point-to-Point & Broadcast modes are working, Able to display the count on 7-Seg Display on SJOne board.
−
| 11/26/2014
+
| 10/19/2014
 
|-
 
|-
−
! scope="row"| 9
+
! scope="row"| 4
−
| 11/25/2014
+
| 10/21/2014
−
| 12/02/2014
+
| 10/28/2014
 
|  
 
|  
−
  * Final Integration and testing Self_Drive Capability of the Car  
+
  * Layout blueprint for Controller and Module positioning
 +
* Assemble the RC Car with all the controllers and Modules
 +
* Define the Message List by working with other teams
 +
* Start working on CAN Periodic message structure
 
|  
 
|  
−
* Ongoing
+
* Completed
−
| --/--/----
+
: RC car design and module assembly is completed. Need some fine tuning for connections. Message list is generated and periodic message implementation started.
−
|}
+
| 10/28/2014
−
 
 
−
=== Hardware Design ===
 
−
Include Block Diagram
 
−
=== Hardware Interface ===
 
−
Include Pin Diagram, Pin Connectivity Table
 
−
=== Software Design ===
 
−
Include Flow Chart
 
−
=== Implementation ===
 
−
Include Communication Table
 
−
{| class="wikitable"
 
−
|+ Master Controller Communication Table
 
 
|-
 
|-
−
| Message Number
+
! scope="row"| 5
−
| Purpose
+
| 10/28/2014
−
| Data Byte Pattern
+
| 11/04/2014
 +
|
 +
* Complete CAN Periodic message structure to transmit Broadcast
 +
  messages over CAN and establish controlled communication among
 +
  different controllers
 +
* Implement Start condition detection and Fetch boot status from
 +
  all controllers and display the status of each controller
 +
|  
 +
* Completed
 +
: Periodic Message Setup done. Able to receive boot status. Need to work on display of status.
 +
| 11/03/2014
 
|-
 
|-
−
| 0x101
+
! scope="row"| 6
−
| Ask for Boot and Version Info. of all Controllers
+
| 11/04/2014
 +
| 11/11/2014
 
|  
 
|  
−
  Byte[0]: Send a '1'
+
  * Design 'Kill Switch' in co-ordination with Motor Controller team
−
|
+
  and Bridge Controller team
−
|-
+
* Develop a 'CAN Bus Crash' detection and reset CAN Bus methodology
−
| 0x103
+
* Design Automatic Head Light turn ON/OFF functionality by
−
| Sync. Master System Time on all Controllers
+
  working with Sensors Controller team
−
|
+
|  
−
Byte[0-3]: System Time [HH:MM:SS]
+
* Completed
−
|
+
: Kill Switch implemented through Bridge controller. Head Lights implemented. LCD display of Status achieved.
 +
| 11/11/2014
 
|-
 
|-
−
| 0x201
+
! scope="row"| 7
−
| Master Gets Status Update from all controllers
+
| 11/11/2014
−
|
+
| 11/18/2014
−
  Byte[0]: Boot Status
+
|  
−
  Byte[1]: Version Info.
+
  * Implement File Log saving to SD Card at periodic intervals
−
|
+
* Work on Restoring to last known Status if the system crashes while running
−
|-
+
  * Develop Detection technique if controllers are reaching 'Error State'
−
| 0x203
+
|  
−
| Master Gets current Time from all Controllers
+
* Completed
−
|
+
: File Log implemented. Error State is partially implemented. Obstacle detection achieved. Needed refinement in Direction control logic. Need to implement reverse logic.
−
Byte[0-3]: Time in [HH:MM:SS]
+
| 11/18/2014
−
|
 
 
|-
 
|-
−
| 0x301
+
! scope="row"| 8
−
| Master Enable Main UI in Android
+
| 11/18/2014
−
|
+
| 11/25/2014
−
Byte[0]: Send a '1'
+
|
−
|
+
* Project Integration and testing Basic Self_Drive Capability of the Car
 +
* Check the Functionality and behavior of all controllers in all the known
 +
  contexts
 +
* Perform modifications (if any) to eliminate any bugs to make the car work
 +
  seamlessly
 +
* Final Integration of car and testing there after
 +
 
 +
|  
 +
* Completed
 +
: Integration Started. Faced difficulty in synchronization.
 +
| 11/26/2014
 
|-
 
|-
−
| 0x302
+
! scope="row"| 9
−
| Master set GPS Destination on Geo Controller
+
| 11/25/2014
−
|
+
| 12/02/2014
−
  Byte[0-3]: Latitude Value
+
|  
−
Byte[4-7]: Longitude Value
+
  * Final Integration and testing Self_Drive Capability of the Car 
−
|
+
|
 +
* completed
 +
: We are able to integrate all the different on-board systems and control the features with the master's control algorithm using real-time data from Sensor, Geo and Bridge controllers. The primary objective of self-drive capability is achieved. We have faced little difficulty in adjusting the frequency of data appropriate to real time needs.
 +
| 12/8/2014
 
|-
 
|-
−
| 0x303
+
! scope="row"| 10
−
| Master set Longitude Way-Points on Geo
+
| 12/02/2014
−
|
+
| 12/18/2014
−
  bytes [0-1] : Total Way-Points count
+
|  
−
bytes [2-3] : Way-Point index
+
  * Final Testing with all Features 
−
bytes [4-7] : Longitude(float)
+
|
−
|
+
* completed
 +
: Checked out the Data Log for any possible message drops. Resolved issues related to Compass.
 +
| 12/15/2014
 
|-
 
|-
−
| 0x304
+
|}
−
| Master set Latitude Way-Points on Geo
+
 
−
|
+
==== Hardware Design ====
−
bytes [0-1] : Total Way-Points count
+
* An RC car was used as a base to demonstrate the Self-Driven Capability of a car with all the Controlling done by SJOne boards.
−
bytes [2-3] : Way-Point index
+
* The hardware for this Project is custom designed according to the requirements of the project.
−
bytes [4-7] : Latitude(float)
+
* This includes building the Chassis to place all the SJOne boards.
−
|
+
* Sufficient Power and Ground slots for all the Sensors, GPS, Compass, LCD breakout boards.
 +
* Designing a CAN bus structure for establishing communication among different SJOne boards.
 +
* Designing a Spike protection for the Input power supply.
 +
* Finally Sufficient number of pins(if necessary) to connect external Breakout boards to the SJOne controllers.
 +
 
 +
==== Hardware Implementation ====
 +
* First we have started by designing the chassis using a PCB as base to place all the SJOne boards that represents the 6 sub-teams,this includes a separate base for placing LCD module, Head-lights and Tail-lamps.
 +
* As a second step we moved forward by designing the circuitry for Power Supply and Spike protection by designing a 5V voltage regulator, that serves as a power supply to all the SJOne controllers and LCD module.
 +
* Then sufficient VCC and GND slots were added to the PCB that could accommodate Sonar sensors, GPS and Compass modules, Head-lights and Tail-lamps.
 +
* Later a common CAN bus structure was designed to support the CAN transceivers for each individual SJOne board. The entire system is built around this CAN structure.
 +
* Then the Hardware was made robust enough to take all the hits during the testing process.
 +
 
 +
 
 +
Following is the top view of the car showing the connection of all the 6 controllers and the hardware interfaced to each of them.
 +
 
 +
[[File: Cmpe243_team3_Block.JPG|600px|center]]
 +
 
 +
==== Hardware Challenges and Difficulties ====
 +
* The major challenge is to design a common CAN bus structure. One need to understand the electrical characterisitcs of CAN in order to design it better. We had to go through several debugging stages to evaluate the perfromance of the CAN bus as it used to fail at times.
 +
* Care must be taken in designing the connections for CAN-HIGH and CAN_LOW. The supply for each CAN needed to be separate in our case in order to provide sufficient drive current to the CAN transceiver.
 +
* Next to this another challenge was to make the Hardware robust. During the testing phase it takes a lot of hits and bangs, the module fitting and the circuitary needs to be good enough to absorb all the pressure. By reducing the number of wired connections the robability of hardware fails can be reduced.
 +
* Another difficulty was to supply PWM signals to the Motor. The Signals should be strong enough to run the DC motor and Servo motor of the car. It happened to be that if the trace/wire connection is too long the PWM signal is losing its strength. So it should be as much near to the motor as possible.
 +
* The positioning of the Sonar sensors should be appropriate to avoid any bounce off, To deal with the bouncing effect we should place it at some height/angular height to reduce the possiblity of bouncing from the ground. Also each sensor should be at a distance and angle with respect to other sensors to facilitate sufficient area of detection.
 +
* The positioning of Compass module is a little bit tricky. This should be far away from Electrical/Magnetic interferences as it very sensitive to these effects. So we placed it on the top at a height to avoid any corrupted values.
 +
 
 +
==== Hardware Interface ====
 +
{| style="width:800px;" |
 +
|[[File:CMPE_TEAM3_Master_block.jpg|800px|thumb|Block diagram of Master controller ]]
 +
|}
 +
 
 +
{| class="wikitable"
 +
|+ Master Controller Pin Connectivity Table
 
|-
 
|-
−
| 0x305
+
! scope="col"| '''Description'''
−
| Master Send GPS FIX Ack to Bridge
+
! scope="col"| '''Your Device Port'''
−
|
+
! scope="col"| '''SJOne Development Board Port'''
−
Byte[0]: Send a value '1'
 
−
|
 
 
|-
 
|-
−
| 0x306
+
| Supply Voltage
−
| Master Send Dest. Reached Ack to Bridge
+
| Supply +5V
−
|
+
| Board +5V
−
Byte[0]: Send a Value '1'
 
−
|
 
 
|-
 
|-
−
| 0x500
+
| Ground
−
| Display Boot and Version Info. on LCD
+
| Supply GND
−
|
+
| Board GND
−
Byte[0]: Boot Status Response
 
−
Byte[1]: Version Info.
 
−
|
 
 
|-
 
|-
−
| 0x501
+
| CAN Transceiver
−
| Display Controllers Time on LCD
+
| Pin no. 1 Driver Input
−
|
+
Pin no. 4 Receiver Output
−
Byte[0-3]: Time in [HH:MM:SS]
+
| P0.1 CAN TD1
−
|
+
P0.0 CAN RD1
 
|-
 
|-
−
| 0x502
+
| Head Lights
−
| Display Destination Has Reached
+
| LED +3.3V
−
|
+
LED GND
−
Byte[0]: Send a '1'
+
| Pin 1.20, 1.22 GPIO
−
|
+
Common GND
 
|-
 
|-
−
| 0x503
+
| LED Strip
−
| Master Set Speed and Direction of Motor
+
| LED Strip DIN
−
|
+
LED Strip +5V
−
Byte[0]: LEFT/RIGHT (or) FRONT/BACK command
+
 
−
|
+
LED Strip GND
 +
| Pin 1.29 GPIO
 +
Common VCC
 +
 
 +
Common GND
 
|-
 
|-
−
| 0x504
+
|}
−
| Display Speed of Motor on LCD
+
 
−
|
+
==== Software Design ====
−
Byte[0]: Speed Value
+
* Master controller which is the central controller, performs all its functions with FreeRTOS software running at its core.
−
|
+
* The two key components of FreeRTOS utilized by Master to achieve these operations are
−
|-
+
: 1. FreeRTOS Task and Scheduler
−
| 0x505
+
: 2. FreeRTOS Queues
−
| Display GPS and Compass values on LCD
+
* Master controller heavily rely on the FreeRTOS scheduler, for most of the time to run various tasks, which are responsible for what the master controller does.
−
|
+
* The FreeRTOS queue structure is used to achieve inter-task communication inside the Master controller to process data and transmit to respective controllers.
−
Byte[0-1]: New Degree to Head
+
* CAN bus structure with 29 bit message ids is used to establish communication among different controllers. The Broadcast bus made point to point to exchange data between any two controllers by configuring an additional Acceptance filter.
−
Byte[2-3]: Dist to Destination
+
* The periodic CAN message structure provided by Preet helps transmit specific data to specified destination at a specified interval like 1Hz, 5Hz, 10Hz etc.
−
Byte[4-5]: Current Degree value
+
* The File logger task runs along with other tasks to log real time data onto SD card in order to facilitate debugging without sacrificing the speed for debugging.
−
|
+
* Additional features like Light sensor controlled Head Lights are implemented to make the car feasible for low light/night time runs.
−
|-
+
* Apart form this an LED strip is used to indicate when the car is being run on sensor's data, when an obstacle is detected. This distinctively demonstrates when the car is controlled by a particular controller among the Geographical controller and Sensor controller.
−
|0x506
+
 
−
| Display Sensor Values on LCD
+
==== Software Implementation ====
−
|
+
* The implementation of the specified software design for master controller is achieved by using the FreeRTOS and CAN libraries provided by Preet.
−
Byte [0]: Front sensor value in inches
+
* The Master operation starts with the initilization of CAN Bus and configuring the CAN acceptance filter. The sample code is shown below.
−
Byte [1]: Front Left sensor value in inches
+
 
−
Byte [2]: Front Right sensor value in inches
+
 
−
Byte [3]: Back sensor value in inches
+
[[File: CmpE243_F14_T3_CAN_INIT.PNG | center]]
−
|
+
 
−
|-
+
 
−
|0x507
+
* In main the control next creates new tasks like Receive task to deal with different functions, which will only start running after the scheduler.
−
| Display Battery Status on LCD
+
*These tasks supply Data to periodic tasks next in the line to Transmit data over the CAN bus to the specified destination.
−
|
+
 
−
Byte[0]: Battery Status Value
+
 
−
|
+
[[File: CmpE243_F14_T3_Tasks.PNG‎ | center]]
−
|-
+
 
−
|}
+
 
 +
[[File: CmpE243_F14_T3_Periodic.PNG |center]]
  
−
=== Testing and Technical Challenge ===
 
  
−
== Motor Controller ==
+
* The FreeRTOS queues exchange data among different tasks to process the data. This comprises data from Sensors, Geo and Bridge Controllers.
−
Group Members:
+
* The Processed data put into the Decision making algorithm performs direction and speed controlling operations.
−
'''''Shashank Tupkar'''''
 
−
'''''Naghma Anwar'''''
 
−
'''''Shiva Moballegh'''''
 
−
'''Motor Controller Team Schedule'''
 
  
−
{| class="wikitable"
+
 
−
|-
+
The software design and implementation of the master controller is explained by the flowchart.
−
! scope="col"| Week No.
+
 
−
! scope="col"| Start Date
+
[[file: CMPE243_Master_1.jpg | left]]
−
! scope="col"| Planned End Date
+
 
−
! scope="col"| Task
+
==== Implementation ====
−
! scope="col"| Status
+
{| class="wikitable"
−
! scope="col"| Actual End Date
+
|+ Master Controller Communication Table
 
|-
 
|-
−
! scope="row"| 1
+
| Message Number
−
| 9/30/2014
+
| Purpose
−
| 10/7/2014
+
| Data Byte Pattern
−
|
 
−
* Study SJOne board's motor controller concepts and PWM
 
−
|
 
−
* Completed
 
−
: Very simple code. Just two lines. Set the frequency. Set the duty cycle.
 
−
| 10/7/2014
 
 
|-
 
|-
−
! scope="row"| 2
+
| 0x101
−
| 10/7/2014
+
| Ask for Boot and Version Info. of all Controllers
−
| 10/14/2014
 
 
|  
 
|  
−
  * Open up RC Car's motor and servo connections
+
  Byte[0]: Send a '1'
−
* Study the Electronic Speed Control's functions
+
|
−
|  
+
|-
−
* Completed
+
| 0x103
−
: Motor and Servo operate on the same frequency
+
| Sync. Master System Time on all Controllers
−
: ESC needs calibration each time it is switched on. Need to find a solution for this.
+
|
−
| 10/11/2014
+
Byte[0-3]: System Time [HH:MM:SS]
−
|-
 
−
! scope="row"| 3
 
−
| 10/14/2014
 
−
| 10/21/2014
 
 
|
 
|
−
* Define the duty cycles for proper motor and servo signals
 
−
|
 
−
* Completed
 
−
: Using trial and error, figured out the duty cycle for constant speed and turns
 
−
| 10/19/2014
 
 
|-
 
|-
−
! scope="row"| 4
+
| 0x201
−
| 10/21/2014
+
| Master Gets Status Update from all controllers
−
| 10/28/2014
+
|
 +
Byte[0]: Boot Status
 +
Byte[1]: Version Info.
 
|
 
|
−
* Add CAN frame structure to the motor functions
 
−
* Test for communication between motors and sensors for prototype demo
 
−
* Define the Message List by working with other teams
 
−
|
 
−
* Completed
 
−
| 11/04/2014
 
 
|-
 
|-
−
! scope="row"| 5
+
| 0x203
−
| 10/28/2014
+
| Master Gets current Time from all Controllers
−
| 11/04/2014
+
|
 +
Byte[0-3]: Time in [HH:MM:SS]
 
|
 
|
−
* Start working on CAN Periodic message structure
 
−
* Start looking for speed sensors
 
−
|
 
−
* Completed
 
−
: Bought magnetic speed sensor from Traxxas telemetry
 
−
: from local RC Car store
 
−
| 11/04/2014
 
 
|-
 
|-
−
! scope="row"| 6
+
| 0x301
−
| 11/04/2014
+
| Master Enable Main UI in Android
−
| 11/11/2014
+
|
−
|
+
  Byte[0]: Send a '1'
−
* Attach speed sensors to the motor
+
|
−
  * Test CAN communication between motor controller and other controllers
 
−
|
 
−
* Completed
 
−
: Speed sensors attached
 
−
| 11/11/2014
 
 
|-
 
|-
−
! scope="row"| 7
+
| 0x302
−
| 11/11/2014
+
| Master set GPS Destination on Geo Controller
−
| 11/18/2014
+
|
−
|  
+
  Byte[0-3]: Latitude Value
−
  * Work on speed sensors. Figure out the way to send sensor data to master controller.
+
  Byte[4-7]: Longitude Value
−
  * Test for proper and accurate CAN communication
+
|
−
|
 
−
* Completed
 
−
| 11/18/2014
 
 
|-
 
|-
−
! scope="row"| 8
+
| 0x303
−
| 11/18/2014
+
| Master set Longitude Way-Points on Geo
−
| 11/25/2014
+
|
−
|  
+
  bytes [0-1] : Total Way-Points count
−
  * Project Integration and testing basic self drive capability of the car
+
  bytes [2-3] : Way-Point index
−
  * Check the functionality and behavior of the motor controller in all the known
+
  bytes [4-7] : Longitude(float)
−
  contexts
+
|
−
  * Perform modifications (if any) to eliminate any bugs to make the motor work
 
−
  seamlessly
 
−
* Final Integration of car and testing there after
 
−
 
 
−
|
 
−
* Ongoing
 
−
| --/--/----
 
−
 
 
−
|}
 
−
 
 
−
=== Hardware Design ===
 
−
Include Block Diagram
 
−
=== Hardware Interface ===
 
−
Include Pin Diagram, Pin Connectivity Table
 
−
=== Software Design ===
 
−
Include Flow Chart
 
−
=== Implementation ===
 
−
Include Communication Table
 
−
{| class="wikitable"
 
−
|+ Motor Controller Communication Table
 
 
|-
 
|-
−
| Message Number
+
| 0x304
−
| Purpose
+
| Master set Latitude Way-Points on Geo
−
| Data layout
 
−
|-
 
−
| 0x508
 
−
| Speed Sensor Data
 
 
|
 
|
−
  byte [0] : Speed sensor value in rpm
+
  bytes [0-1] : Total Way-Points count
−
|-  
+
bytes [2-3] : Way-Point index
−
| 0x509
+
bytes [4-7] : Latitude(float)
−
| Vehicle Direction/Movement Data
 
 
|
 
|
−
byte [0] : Movement Control
 
−
      0x1 : Forward
 
−
      0x2 : Reverse
 
−
      0x3 : Stop
 
−
byte [1] : Steering Control
 
−
      0x1 : Left
 
−
      0x2 : Right
 
−
      0x3 : Straight
 
 
|-
 
|-
−
|}
+
| 0x305
−
 
+
| Master Send GPS FIX Ack to Bridge
−
=== Testing and Technical Challenge ===
+
|
−
 
+
Byte[0]: Send a value '1'
−
== Sensor Controller ==
+
|
−
Group Members:
 
−
'''''Deepak Yadav'''''
 
−
'''''Vinod Pangul'''''
 
−
'''Sensor Team Schedule'''
 
−
{| class="wikitable"
 
 
|-
 
|-
−
! scope="col"| Sl.No
+
| 0x306
−
! scope="col"| Start Date
+
| Master Send Dest. Reached Ack to Bridge
−
! scope="col"| End Date
+
|
−
! scope="col"| Task
+
Byte[0]: Send a Value '1'
−
! scope="col"| Status
+
|
−
! scope="col"| Actual Completion Date
 
 
|-
 
|-
−
! scope="row"| 1
+
| 0x500
−
| 10/6/2014
+
| Display Boot and Version Info. on LCD
−
| 10/18/2014
+
|
−
| Order Ultra Sonic Sensors
+
Byte[0]: Boot Status Response
−
| Completed [Got two sensors (front and back), 2 more (front right & left) to order ->Completed.]
+
Byte[1]: Version Info.
−
| 10/19/2014
+
|
 
|-
 
|-
−
! scope="row"| 2
+
| 0x501
−
| 10/9/2014
+
| Display Controllers Time on LCD
−
| 10/9/2014
+
|
−
| Sensor Data Sheet review with the team
+
Byte[0-3]: Time in [HH:MM:SS]
−
| Completed
+
|
−
| 10/9/2014
 
 
|-
 
|-
−
! scope="row"| 3
+
| 0x502
−
| 10/9/2014
+
| Display Destination Has Reached
−
| 10/16/2104
+
|
−
| Sensor code development
+
Byte[0]: Send a '1'
−
| Completed (Implementing filter (HW/SW) to get more accurate data ->(Done). Add logic to get the rest of the three sensor(front right/left and back data)->(Done) (Note: Delayed due to the implementation of CAN structure and calibration of IR sensor)
 
−
| 10/21/2014
 
−
|-
 
−
! scope="row"| 4
 
−
| 10/22/2014
 
−
| 10/25/2014
 
−
| Sensor software testing
 
−
| Ongoing
 
 
|
 
|
 
|-
 
|-
−
! scope="row"| 5
+
| 0x503
−
| 10/25/2014
+
| Master Set Speed and Direction of Motor
−
| 10/28/2014
+
|
−
| Sensor real time testing
+
Byte[0]: LEFT/RIGHT (or) FRONT/BACK command
−
| Ongoing
 
 
|
 
|
 
|-
 
|-
−
! scope="row"| 6
+
| 0x504
−
| 10/13/2014
+
| Display Speed of Motor on LCD
−
| 10/15/2014
+
|
−
| Light sensor code Development
+
Byte[0]: Speed Value
−
| Completed
+
|
−
| 10/14/2014
 
 
|-
 
|-
−
! scope="row"| 7
+
| 0x505
−
| 10/13/2014
+
| Display GPS and Compass values on LCD
−
| 10/15/2014
+
|
−
| Accelerometer sensor code Development to detect tilt
+
Byte[0-1]: New Degree to Head
−
| Completed
+
Byte[2-3]: Dist to Destination
−
| 10/14/2014
+
Byte[4-5]: Current Degree value
−
|-
 
−
! scope="row"| 8
 
−
| 10/15/2014
 
−
| 10/15/2014
 
−
| Light Sensor and Accelerometer Testing
 
−
| Completed
 
−
| 10/15/2014
 
−
|-
 
−
! scope="row"| 9
 
−
| 10/29/2014
 
−
| 10/31/2014
 
−
| Battery status controller circuit Design
 
−
| Ongoing
 
 
|
 
|
 
|-
 
|-
−
! scope="row"| 10
+
|0x506
−
| 11/01/2014
+
| Display Sensor Values on LCD
−
| 11/02/2014
 
−
| Battery status-circuit Testing
 
 
|
 
|
 +
Byte [0]: Front sensor value in inches
 +
Byte [1]: Front Left sensor value in inches
 +
Byte [2]: Front Right sensor value in inches
 +
Byte [3]: Back sensor value in inches
 
|
 
|
 
|-
 
|-
−
! scope="row"| 11
+
|0x507
−
| 11/03/2014
+
| Display Battery Status on LCD
−
| 11/04/2014
 
−
| Common Communication SW code implementation and testing
 
 
|
 
|
 +
Byte[0]: Battery Status Value
 
|
 
|
 
|-
 
|-
−
! scope="row"| 11
+
|0x540
−
| 11/04/2014
+
| Send GPS Data to Bridge
−
| 11/09/2014
 
−
| Complete Hardware testing-1
 
 
|
 
|
 +
Byte[0-1]: Heading Degree
 +
Byte[2-3]: Dist. to Destination
 +
Byte[4-5]: Current Bearing Degree
 +
Byte[6-7]: Difference between Heading and Bearing angle
 
|
 
|
 
|-
 
|-
−
! scope="row"| 12
+
|0x550
−
| 11/10/2014
+
| Send Sensor Data to Bridge
−
| 11/15/2014
 
−
| Complete Hardware testing-2
 
 
|
 
|
 +
Byte[0]: Front Sensor
 +
Byte[1]: Front Right Sensor
 +
Byte[2]: Front Left Sensor
 +
Byte[3]: Back Sensor
 +
Byte[4]: Speed value
 
|
 
|
 +
|-
 
|}
 
|}
  
−
=== Hardware Design ===
+
==== Testing and Technical Challenge ====
−
Include Block Diagram
+
We have faced several Difficulties during Software design implementation for Master Controller. Some of these issues are discussed here.
−
=== Hardware Interface ===
+
* Top of the list is the Integration. We have faced difficulty in achieving the integration of all the individual controllers working together in synchronization with each other.
−
Include Pin Diagram, Pin Connectivity Table
+
* Another issue is the CAN bus communication failure which is due to improper transmitting formats like message ID duplication causing the CAN bus error. There are also issues due to improper configuration of acceptance filter, which is later resolved.
−
=== Software Design ===
+
* We have also faced difficulty when using the FreeRTOS queues, This is caused due to using a particular queue at some locations before it is actually declared declared.
−
Include Flow Chart
+
* Apart from this the Queue timing implementation has to be observed carefully as it may conflict the frequency of real time Data that causes error status as the receiving queue task cannot see any data on the queue.
−
=== Implementation ===
+
* We have faced difficulty in data synchronization during testing. The real-time data needs forced us to modify the Transmitting frequencies from certain controllers, particularly for Geographical controller.
−
Include Communication Table
+
 
 +
== '''Motor Controller''' ==
 +
==== Group Members ====
 +
'''''Shashank Tupkar'''''
 +
'''''Naghma Anwar'''''
 +
'''''Shiva Moballegh'''''
 +
==== Motor Controller Team Schedule ====
 +
 
 
{| class="wikitable"
 
{| class="wikitable"
−
|+ Sensor Controller Communication Table
 
 
|-
 
|-
−
| Message Number
+
! scope="col"| Week No.
−
| Purpose
+
! scope="col"| Start Date
−
| Data layout
+
! scope="col"| Planned End Date
 +
! scope="col"| Task
 +
! scope="col"| Status
 +
! scope="col"| Actual End Date
 +
|-
 +
! scope="row"| 1
 +
| 9/30/2014
 +
| 10/7/2014
 +
|
 +
* Study SJOne board's motor controller concepts and PWM
 +
|
 +
* Completed
 +
: Very simple code. Just two lines. Set the frequency. Set the duty cycle.
 +
| 10/7/2014
 
|-
 
|-
−
| 0x510
+
! scope="row"| 2
−
| Front/Back Range Sensor Data
+
| 10/7/2014
 +
| 10/14/2014
 +
|
 +
* Open up RC Car's motor and servo connections
 +
* Study the Electronic Speed Control's functions
 +
|
 +
* Completed
 +
: Motor and Servo operate on the same frequency
 +
: ESC needs calibration each time it is switched on. Need to find a solution for this.
 +
| 10/11/2014
 +
|-
 +
! scope="row"| 3
 +
| 10/14/2014
 +
| 10/21/2014
 
|
 
|
−
byte [0] : Front sensor value in inches
+
* Define the duty cycles for proper motor and servo signals
−
byte [1] : Front Left sensor value in inches
+
|
−
byte [2] : Front Right sensor value in inches
+
* Completed
−
byte [3] : Back sensor value in inches
+
: Using trial and error, figured out the duty cycle for constant speed and turns
−
|-  
+
| 10/19/2014
−
| 0x511
+
|-
−
| Accelerometer/Light/Battery Sensor Data
+
! scope="row"| 4
 +
| 10/21/2014
 +
| 10/28/2014
 
|
 
|
−
byte [0] : X axis Value
+
* Add CAN frame structure to the motor functions
−
byte [1] : Y axis Value
+
* Test for communication between motors and sensors for prototype demo
−
byte [2] : Z axis Value
+
* Define the Message List by working with other teams
−
byte [3] : Light sensor value
+
|
−
byte [4] : Battery status value
+
* Completed
−
|-  
+
| 11/04/2014
−
|}
+
|-
−
 
+
! scope="row"| 5
−
=== Testing and Technical Challenge ===
+
| 10/28/2014
−
 
+
| 11/04/2014
−
== Geographical Controller ==
+
|
−
Group Members:
+
* Start working on CAN Periodic message structure
−
'''''Bhushan Gopala Reddy'''''
+
* Start looking for speed sensors
−
'''''Ryan Marlin'''''
+
|
−
'''''Rishikesh Nagare'''''
+
* Completed
−
'''Geographical Team Schedule'''
+
: Bought magnetic speed sensor from Traxxas telemetry
−
 
+
: from local RC Car store
−
{| class="wikitable"
+
| 11/04/2014
 
|-
 
|-
−
! scope="col"| Sl.No
+
! scope="row"| 6
−
! scope="col"| Start Date
+
| 11/04/2014
−
! scope="col"| End Date
+
| 11/11/2014
−
! scope="col"| Task
+
|  
−
! scope="col"| Status
+
* Attach speed sensors to the motor
−
! scope="col"| Actual Completion Date
+
* Test CAN communication between motor controller and other controllers
−
|-
+
|  
−
! scope="row"| 1
+
* Completed
−
| 10/4/2014
+
: Speed sensors attached
−
| 10/13/2014
+
| 11/11/2014
−
| Research and Order GPS module
 
−
| Received GPS module
 
−
| 10/7/2014
 
−
|-
 
−
! scope="row"| 2
 
−
| 10/7/2014
 
−
| 10/18/2014
 
−
| Interface GPS module with LPC1758
 
−
| Finished
 
−
| 10/17/14
 
−
|-
 
−
! scope="row"| 3
 
−
| 10/14/2014
 
−
| 10/18/2014
 
−
| Receive Compass module from Preet
 
−
| Received
 
−
| 10/9/2014
 
−
|-
 
−
! scope="row"| 4
 
−
| 10/18/2014
 
−
| 11/4/2014
 
−
| Parse GPS data and setup constructs to send appropriate data
 
−
| Ongoing
 
−
| |
 
−
|-
 
−
! scope="row"| 5
 
−
| 10/14/2014
 
−
| 10/18/2014
 
−
| Interface the Compass Module
 
−
| Finished
 
−
| 10/16/2014
 
−
|-
 
−
! scope="row"| 6
 
−
| 10/25/2014
 
−
| 11/4/2014
 
−
| Calibration of Compass
 
−
| Code completed. Need to test using the car
 
−
| --/--/----
 
 
|-
 
|-
 
! scope="row"| 7
 
! scope="row"| 7
−
| 11/4/2014
 
 
| 11/11/2014
 
| 11/11/2014
−
| Integrate GPS and Compass data
+
| 11/18/2014
−
| Ongoing
 
 
|  
 
|  
−
|-
+
* Work on speed sensors. Figure out the way to send sensor data to master controller.
 +
* Test for proper and accurate CAN communication
 +
|
 +
* Completed
 +
| 11/18/2014
 +
|-
 
! scope="row"| 8
 
! scope="row"| 8
−
| 10/25/2014
 
−
| 11/09/2014
 
−
| Testing and mapping of GPS co-ordinates
 
−
| Ongoing
 
−
|
 
−
|-
 
−
! scope="row"| 9
 
 
| 11/18/2014
 
| 11/18/2014
 
| 11/25/2014
 
| 11/25/2014
−
| Final integration and testing
 
 
|  
 
|  
 +
* Project Integration and testing basic self drive capability of the car
 +
* Check the functionality and behavior of the motor controller in all the known contexts
 +
* Perform modifications (if any) to eliminate any bugs to make the motor work seamlessly
 +
* Final Integration of car and testing there after
 +
 
 
|  
 
|  
 +
* Completed
 +
| 12/12/2014
 +
 
|}
 
|}
  
−
=== Hardware Design ===
+
==== Hardware Design ====
−
Include Block Diagram
+
[[File:CmpE243_F14_T3_Hardware.png|Anatomy of The Rustler]]
−
=== Hardware Interface ===
+
===== Parts and their functions =====
−
Include Pin Diagram, Pin Connectivity Table
+
[[File:CmpE243_F14_T3_Motor.png|thumb|right|Velineon 3500 Brushless Motor]]
−
=== Software Design ===
+
'''''Motor''''' : Our RC car came with Velineon 3500 Brushless Motor. One of the main drawbacks of brushless motor is that it requires a speed controller to change the field polarity. We can't just give power to the motor directly and expect it to go. We can almost consider the controller as an integral part of the motor itself.
−
Include Flow Chart
+
 
−
=== Implementation ===
+
[[File:CmpE243_F14_T3_ESC.png|thumb|left|Velineon VXL-3s ESC]]
−
Include Communication Table
+
'''''ESC''''' : Electronic speed controller was the trickiest part to deal with, since it comes with a previously programmed microcontroller inside it. It needs callibration, for which you need to refer to the user manual. An electronic speed controller basically controls the power given to the motor. Our RC car came with VXL-3s ESC, which accepted 100 Hz PWM input signal whose duty cycle varied from 10% to 20%. When supplied with a 15% duty cycle at 100 Hz, the ESC responded by turning off the motor attached to its output.
 +
 
 +
'''''Steering Servo''''' : Our RC car was equipped with a digital servo (Traxxas part #2075) for steering control. It does not require an ESC to operate. We can give PWM signal directly to the servo from the SJOne board. The servo accepted 100 Hz PWM input signal whose duty cycle varied from 10% to 20%, where 10% represents extreme right turn and 20% represents extreme left turn.[[File:CmpE243_F14_T3_Servo.jpg|thumb|right|Steering Servo]]
 +
 
 +
'''''Speed Sensor''''' : To measure the RPM and speed of our car, we used the speed sensor provided by Traxxas Telemetry. This magnetic speed sensor worked on Hall effect. To learn more about Hall effect sensors, you can click on this [http://en.wikipedia.org/wiki/Hall_effect_sensor wikipedia article]. Since the sensor was provided by the same brand of our car, the installation was quick and easy. Here's a reference [https://www.youtube.com/watch?v=xx-Ft_kzTzs video] on how to attach magnetic speed sensor to the RC car.
 +
 
 +
[[File:CmpE243_F14_T3_Battery.jpg|thumb|left|Traxxas 7-Cell 8.4V NiMH Battery Pack]]
 +
'''''Battery''''' : We used 7 Cell NiMH (Nickel-Metal Hydride) battery pack for our car but would recommend others to use Lipo (Lithium Polymer) batteries instead. NiMH batteries tend to discharge very quickly. Also we realized later that since this car was made for racing purpose, its speed was too fast for our project. We reduced the voltage by removing 2 cells from the 7 cell battery pack. So, go for the 5 cell battery pack instead. A Traxxas EZ-Peak Charger would help a lot while doing testing.
 +
 
 +
'''''Gears''''' : Gears also play an important role in determining the Speed of the car. A gear is defined by the number of Cogs (teeth) which determines if the gear increases (or) decreases the output speed delivered to the axle. So, we can also opt for different gears to reduce the overall speed in any case necessary. In our case changing the gears isn't an option since our car is set with the minimum gear as it belongs to sports car category. But however some custom gears can still do the job in reducing the unnecessary speed, though they are a little bit hard to get our hands on it.
 +
 
 +
==== Hardware Interface ====
 +
===== Motor, Servo and Speed Sensor Interface =====
 +
[[File:CmpE243_F14_T3_PinConnection.png]]
 +
 
 
{| class="wikitable"
 
{| class="wikitable"
−
|+ GPS Controller Communication Table
+
|+ Motor Controller Pin Connectivity Table
 
|-
 
|-
−
| Message Number
+
! scope="col"| '''Description'''
−
| Purpose
+
! scope="col"| '''Your Device Port'''
−
| Data layout
+
! scope="col"| '''SJOne Development Board Port'''
 +
! scope="col"| '''Commands'''
 +
! scope="col"| '''Note'''
 
|-
 
|-
−
| 0x518
+
| Supply Voltage
−
| Send GPS Data to Master
+
| 6V from NiMH battery
−
|
+
| N/A
−
  byte [0] : New Degree
+
|
−
  byte [1] : Distance
+
|
−
  byte [2] : Current Degree
 
 
|-
 
|-
−
| 0x519
+
| Ground
−
| Send GPS FIX ACK to Master
+
| GND (Black Wire)
−
|
+
| GND
−
  byte[0]: Send a '1'
+
|
 +
|
 
|-
 
|-
−
| 0x52A
+
| ESC
−
| Send Destination Reached ACK to master
+
|
−
|
+
  Control (White Wire)
−
   byte[0]: Send a '1'
+
|
 +
   P2.0 PWM
 +
|
 +
  PWM motor(PWM::''pwm1'', 101);
 +
  motor.set(14.5);
 +
|
 +
  Sets PWM signal of 101 Hz
 +
  Sets duty cycle of 14.5% for forward movement
 
|-
 
|-
−
|}
+
| Servo
−
 
+
|
−
=== Testing and Technical Challenge ===
+
  Control (White Wire)
−
 
+
|
−
== Android & Communication Bridge Controller ==
+
  P2.1 PWM
−
Group Members:
+
|
−
'''''Chia Pin Tseng'''''
+
  PWM servo(PWM::''pwm2'', 101);
−
'''''Johnny Yam'''''
+
  servo.set(15);
−
'''''Kevin Beadle'''''
+
|
−
'''Communication Bridge & Android Team Schedule'''
+
  Sets PWM signal of 101 Hz
−
 
+
  Sets duty cycle of 15% for no turn
−
{| class="wikitable"
 
 
|-
 
|-
−
! scope="col"| Sl.No
+
| Speed Sensor
−
! scope="col"| Start Date
+
|
−
! scope="col"| Planned End Date
+
  Signal (White Wire)
−
! scope="col"| Task
+
|
−
! scope="col"| Status
+
  P2.2 PWM
−
! scope="col"| Actual End Date
+
|
 +
 
 +
|
 +
  It contains a trigger magnet and an rpm sensor
 +
  It works on Hall effect.
 
|-
 
|-
−
! scope="row"| 1
+
| CAN Transceiver
−
| 9/30/2014
+
|
−
| 9/30/2014
+
  Pin no. 1 Driver Input
−
| Obtain Bluetooth Module (already had one)
+
  Pin no. 4 Receiver Output
−
| Done
+
|
−
| 9/30/2014
+
  P0.1 CAN TD1
 +
  P0.0 CAN RD1
 +
|
 +
|
 +
  TI CAN Transceiver SN65HVD232D
 +
  Pin 7 - CAN H & Pin 6 - CAN L
 +
|-
 +
|}
 +
 
 +
==== Software Flow ====
 +
[[File: CmpE243_F14_T3_MotorFC.jpg]]
 +
 
 +
==== Implementation ====
 +
 
 +
{| class="wikitable"
 +
|+ Motor Controller Communication Table
 
|-
 
|-
−
! scope="row"| 2
+
| Message Number
−
| 9/30/2014
+
| Purpose
−
| 10/14/2014
+
| Data layout
−
| Develop Basic Android App with Bluetooth Sensor Communication
 
−
| Done
 
−
| 10/7/2014
 
 
|-
 
|-
−
! scope="row"| 3
+
| 0x508
−
| 10/11/2014
+
| Speed Sensor Data
−
| 10/14/2014
+
|
−
| Interface Bluetooth Module with SJSU Dev Board
+
byte [0] : Speed sensor value in rpm
−
| Done
+
|-
−
| 10/11/2014
+
| 0x503
 +
| Vehicle Direction/Movement Data
 +
|
 +
byte [0] : Movement Control
 +
      0x1 : Forward Fast
 +
      0x2 : Forward Slow
 +
      0x3 : Right
 +
      0x4 : Left
 +
      0x5 : Stop
 +
      0x6 : Back Right
 +
      0x7 : Back Left
 +
      0x8 : Back
 
|-
 
|-
−
! scope="row"| 4
+
|}
−
| 10/12/2014
+
 
−
| 10/19/2014
+
==== Testing and Technical Challenge ====
−
| Be able to send bi-directional arbitrary messages between Android App and Dev Board via Bluetooth
+
*Motor Controller
−
| Done
+
**ESC
−
| 10/14/2014
+
***Electronic Speed Control is tricky to handle since it has its own pre-programmed micro-controller inside it which needs calibration according to the user manual.
 +
***We started with calibrating the ESC using RC car's transmitter, but later we had to write our own calibration code.
 +
**Motor
 +
***We tested the motor speed by measuring the PWM signal on oscilloscope. We started by reading the PWM signal on oscilloscope while manipulating the speed of the RC car using its transmitter module.
 +
***Since the car was made for racing purpose, we had to keep the speed to its lowest value.
 +
***The transmitter and receiver of the RC car was detached from it. We gave PWM signal to the ESC and Servo through SJOne board.
 +
***It turned out that ESC was not accepting the PWM signal because it needed calibration each time its setting is changed.
 +
***We overcame this problem by including a calibration init code in our program.
 +
***We also noticed that as we added more hardware on top of the car, its speed was affected because of the load. We had to change the PWM value accordingly.
 +
**Servo
 +
***Since servo was not connected to the ESC it was pretty easy to handle. We could give PWM signal directly to servo and it moved accordingly.
 +
 
 +
== '''Sensor Controller''' ==
 +
==== Group Members ====
 +
'''''Deepak Yadav'''''
 +
'''''Vinod Pangul'''''
 +
==== Sensor Team Schedule ====
 +
{| class="wikitable"
 
|-
 
|-
−
! scope="row"| 5
+
! scope="col"| Sl.No
−
| 10/14/2014
+
! scope="col"| Start Date
−
| 11/21/2014
+
! scope="col"| End Date
−
| Subscribe to all CAN messages and dump all of them via Bluetooth to Android App or web interface
+
! scope="col"| Task
−
| Done
+
! scope="col"| Status
−
| 11/24/2014
+
! scope="col"| Actual Completion Date
 
|-
 
|-
−
! scope="row"| 6
+
! scope="row"| 1
−
| 10/14/2014
+
| 10/6/2014
−
| 11/21/2014
+
| 10/18/2014
−
| Ajax & Websocket server remote structure
+
| Order Ultra Sonic Sensors
−
| Done
+
| Completed [Got two sensors (front and back), 2 more (front right & left) to order ->Completed.]
−
| 11/01/2014
+
| 10/19/2014
 
|-
 
|-
−
! scope="row"| 7
+
! scope="row"| 2
−
| 10/14/2014
+
| 10/9/2014
−
| 11/21/2014
+
| 10/9/2014
−
| Be able to input GPS coordinates through either (or both) Android App and web interface and send through Bluetooth then CAN bus
+
| Sensor Data Sheet review with the team
−
| Done
+
| Completed
−
| 11/24/2014
+
| 10/9/2014
 
|-
 
|-
−
! scope="row"| 8
+
! scope="row"| 3
 +
| 10/9/2014
 +
| 10/16/2104
 +
| Sensor code development
 +
| Completed (Implementing filter (HW/SW) to get more accurate data ->(Done). Add logic to get the rest of the three sensor(front right/left and back data)->(Done) (Note: Delayed due to the implementation of CAN structure and calibration of IR sensor)
 
| 10/21/2014
 
| 10/21/2014
−
| 11/24/2014
 
−
| Android App and webpage GUI enhancements (Google Maps, Google Drive)
 
−
| Done
 
−
| 11/24/2014
 
 
|-
 
|-
−
! scope="row"| 9
+
! scope="row"| 4
−
| 10/21/2014
+
| 10/22/2014
−
| 11/30/2014
+
| 10/25/2014
−
| Data visualization (status, compass, speed, location,....)
+
| Sensor software testing
−
| On going
+
| Completed
−
| TBD
+
| 10/25/2014
−
|}
 
−
 
 
−
=== Hardware Design ===
 
−
Include Block Diagram
 
−
=== Hardware Interface ===
 
−
Include Pin Diagram, Pin Connectivity Table
 
−
=== Software Design ===
 
−
Include Flow Chart
 
−
=== Implementation ===
 
−
Include Communication Table
 
−
=== Testing and Technical Challenge ===
 
−
 
 
−
== I/O Unit Controller ==
 
−
Group Members:
 
−
'''''Shreeram Gopalakrishnan'''''
 
−
'''''Sreeharsha Paturu Gangadhara'''''
 
−
'''IO Team Schedule'''
 
−
 
 
−
{| class="wikitable"
 
 
|-
 
|-
−
! scope="col"| Sl.No
+
! scope="row"| 5
−
! scope="col"| Start Date
+
| 10/25/2014
−
! scope="col"| End Date
+
| 10/28/2014
−
! scope="col"| Task
+
| Sensor real time testing
−
! scope="col"| Status
+
| Completed
−
! scope="col"| Actual Completion Date
+
| 10/28/2014
 
|-
 
|-
−
! scope="row"| 1
+
! scope="row"| 6
−
| 10/7/2014
 
−
| 10/13/2014
 
−
| Research and Order LCD Display
 
−
| Ordered LCD Display
 
 
| 10/13/2014
 
| 10/13/2014
 +
| 10/15/2014
 +
| Light sensor code Development
 +
| Completed
 +
| 10/14/2014
 
|-
 
|-
−
! scope="row"| 2
+
! scope="row"| 7
 +
| 10/13/2014
 +
| 10/15/2014
 +
| Accelerometer sensor code Development to detect tilt
 +
| Completed
 
| 10/14/2014
 
| 10/14/2014
−
| 10/21/2014
 
−
| Interfacing LCD Display with LPC1758
 
−
| Completed
 
−
| 10/21/2014
 
 
|-
 
|-
−
! scope="row"| 3
+
! scope="row"| 8
−
| 10/21/2014
+
| 10/15/2014
−
| 10/28/2014
+
| 10/15/2014
−
| Implementing CAN structure with LCD tasks.
+
| Light Sensor and Accelerometer Testing
 
| Completed
 
| Completed
−
| 11/30/2014
+
| 10/15/2014
 
|-
 
|-
−
! scope="row"| 4
+
! scope="row"| 11
−
| 10/28/2014
+
| 11/03/2014
 +
| 11/04/2014
 +
| Common Communication SW code implementation and testing
 +
| Completed
 
| 11/04/2014
 
| 11/04/2014
−
| Subscribe data from motor, sensor and GPS controller,display it on LCD.
 
−
| Ongoing
 
−
|
 
 
|-
 
|-
−
! scope="row"| 5
+
! scope="row"| 11
 
| 11/04/2014
 
| 11/04/2014
−
| 11/11/2014
+
| 11/09/2014
−
| Setup hardware and write code for START, STOP and Headlight buttons.
+
| Complete Hardware testing-1
−
| TBD
+
| Completed
−
|
+
| 11/09/2014
 
|-
 
|-
−
! scope="row"| 6
+
! scope="row"| 12
−
| 11/11/2014
+
| 11/10/2014
−
| 11/18/2014
+
| 11/15/2014
−
| Testing and mounting hardware on car.
+
| Complete Hardware testing-2
−
| TBD
+
| Completed
−
|
+
| 11/15/2014
−
|-
 
−
! scope="row"| 7
 
−
| 11/18/2014
 
−
| 11/25/2014
 
−
| Final Testing
 
−
| TBD
 
−
|
 
 
|}
 
|}
  
−
=== Hardware Design ===
+
==== Sensors : Sonar Sensors + Light and Accelerometer sensor====
−
Include Block Diagram
+
 
−
=== Hardware Interface ===
+
==== Hardware Design ====
−
Include Pin Diagram, Pin Connectivity Table
+
 
−
=== Software Design ===
+
[[File:CmpE243_F14_T3_HardwareInterface.png]]
−
Include Flow Chart
+
 
−
=== Implementation ===
+
====A) Sonar Sensor:====
−
Include Communication Table
+
 
 +
[[File:CmpE243_F14_T3_sonarSensor.jpg]]
 +
 
 +
*The LVMax long distance sonar sensors are used to detect the objects. We used four such sensors, three in the front and one in the back to get wide angle vision for the car. The Sonar Sensors sends sound waves when triggered and then the sensor signal emits a PWM that needs to be timed to detect the distance. The PWM width depends on the time it takes for the sound waves to bounce back from an object. The following figure explains how the distance is calculated.
 +
[[File:CmpE243_F14_T3_Sensor.jpg]]
 +
 
 +
====B) Light and Accelerometer Sensor:====
 +
*The inbuilt accelerometer and light sensor on SJoneBoard is used to read their values. The inbuilt driver libraries provide by Prof. Preet is used to read both the accelerometer and the light sensor value and broadcast it over CAN bus for the detection of Car's light and front light of the car.
 +
 
 +
==== Software Design ====
 +
===== Sonar Sensor =====
 +
*Configure PW as input
 +
*Enable PW as Rising and falling edge interrupt
 +
*Configure RX as output, and give a 20uS Pulse of HIGH then LOW
 +
*Take a snapshot of a hardware timer (T1) or start a hardware timer When Rising edge interrupt occur on PW.
 +
--> After few microsecond <--
 +
*PW will go HIGH,take a snapshot of a hardware timer or start a hardware timer When Rising edge interrupt occur
 +
--> After some time <--
 +
*PW will go LOW and the interrupt on falling edge will now trigger, Take a snapshot of a hardware timer (T2).
 +
*Calculate the time difference (T2-T1) and convert the time into inches/CM (Formula is provided by the datasheet).
 +
 
 +
[[File:CmpE243_F14_T3_SensorFlowChart.png]]
 +
 
 +
===== Light and Accelerometer =====
 +
*The library provided with SJOne Board has drivers for light and Accelerometer sensors. The only thing is to be done is to read the light sensor and accelerometer sensor data and broadcast to Master controller over CAN bus at rate of 1Hz.
 +
 
 +
[[File:CmpE243_F14_T3_LightAccl.png]]
 +
 
 +
===== Sensor Controller Task =====
 +
*Below is the overall flowchart of the sensor controller task.
 +
 
 +
[[File:CmpE243_F14_T3_SensorTask.png]]
 +
 
 +
==== Implementation ====
 +
 
 
{| class="wikitable"
 
{| class="wikitable"
−
|+ IO Communication Table
+
|+ Sensor Controller Communication Table
 
|-
 
|-
 
| Message Number
 
| Message Number
Line 1,045: Line 1,120:
 
| Data layout
 
| Data layout
 
|-
 
|-
−
| 0x520
+
| 0x510
−
| Subscribe to Sensor data
+
| Front/Back Range Sensor Data
−
| bytes [0-5] : Sensor Value in Inches
+
|
−
|-
+
byte [0] : Front sensor value in inches
−
| 0x521
+
byte [1] : Front Left sensor value in inches
−
| Subscribe to Motor data
+
byte [2] : Front Right sensor value in inches
−
| bytes [0-2] : Vehicle Direction
+
byte [3] : Back sensor value in inches
−
|-
+
|-  
−
| 0x522
+
| 0x511
−
| Subscribe to Compass Data
+
| Accelerometer/Light Sensor
−
| bytes [0] : Compass Data in degrees
+
|
−
|-
+
byte [0] : X axis Value
−
| 0x523
+
byte [1] : Y axis Value
−
| Subscribe to Battery Status
+
byte [2] : Z axis Value
−
| bytes [0] : Battery Status Value
+
byte [3] : Light sensor value
−
|-
+
|-  
 
|}
 
|}
  
−
=== Testing and Technical Challenge ===
+
==== Testing and Technical Challenge ====
 +
*Front and Back Sensors Controller
 +
**To test the Sonar sensors, We placed the object in front of the sonar sensor and checked the pulse generated by the sonar sensors on Oscilloscope. The sensors data is verified by printing it on the Output terminal. We also tested the working of sensor with the moving car. We logged the data on the SD card and also displayed it on the seven segment display when the car was moving. 
  
−
== Design & Implementation ==
+
We used Maxbotix LV-MaxSonar sensors. It has Three mode for getting data-Pulse width (PW), Analog (AN) and RS232. We went for Pulse width mode, because RS232 found to be very inaccurate and needed more pin connections (RX,TX,GND and 4 UART), SJOne board has only three available analog pins for use and we needed 4 of them and also they were not fast enough and their minimum distance is only 6 inch. So, we decided to go for Pulse width mode. The PW mode are much accurate and they are fast. Their distance range is from 3 inch to 254 inch. Moreover, PW can be connected to GPIO pins with external interrupt functionality. Since SjOne Board has more available GPIO pins on Port2 with external Interrupt functionality, PW mode option was chosen.
−
=== Controller Communication Table ===
+
 
 +
The sonar sensors needs some time of delay to complete the full distance reading if no object is detected within the max range.The delay is ~50ms for each sensor to complete the distance calculation. So, a min 50ms delay is needed between every next triggering of RX pin. The value provided by the sensors are accurate, but not very stable. We tried using mode filters to avoid unstable readings. The only drawback of using filters was that it slowed down the sensors reading. After few experiment we found out that sensors are much more stable and provide a very accurate reading when we put a large delay around 20 ms between toggling the trigger pin (RX) and polling on CPU and not using external interrupt for calculating the distance time. This method is a very bad design as it can consume unnecessary CPU time, and its max range is not accurate and fixed (due to timeout delay), and it may give inaccurate reading if any interrupt occur. Since sensor task had no other major task running and after few experiment we found out that without using external interrupt and just polling the sensor value (bad design approach) was more reliable and accurate!!. The future implementation would be to find the solution to get the more reliable and accurate data using external interrupt function.
 +
 
 +
== '''Geographical Controller''' ==
 +
==== Group Members ====
 +
'''''Bhushan Gopala Reddy'''''
 +
'''''Ryan Marlin'''''
 +
'''''Rishikesh Nagare'''''
 +
==== Geographical Team Schedule ====
  
 
{| class="wikitable"
 
{| class="wikitable"
−
|+ Controllers
 
 
|-
 
|-
−
| Controller ID
+
! scope="col"| Sl.No
−
| Controller Type
+
! scope="col"| Start Date
 +
! scope="col"| End Date
 +
! scope="col"| Task
 +
! scope="col"| Status
 +
! scope="col"| Actual Completion Date
 
|-
 
|-
−
| 0x01
+
! scope="row"| 1
−
| Master Controller
+
|
 +
10/4/2014
 +
|
 +
10/13/2014
 +
|
 +
Research and Order GPS module
 +
|
 +
Received GPS module
 +
|
 +
10/7/2014
 
|-
 
|-
−
| 0x02
+
! scope="row"| 2
−
| Motor Controller
+
|
 +
10/7/2014
 +
|
 +
10/18/2014
 +
|
 +
Interface GPS module with LPC1758
 +
|
 +
Finished
 +
|
 +
10/17/14
 
|-
 
|-
−
| 0x03
+
! scope="row"| 3
−
| Sensor Controller
+
|
 +
10/14/2014
 +
|
 +
10/18/2014
 +
|
 +
Receive Compass module from Preet
 +
|
 +
Received
 +
|
 +
10/9/2014
 
|-
 
|-
−
| 0x04
+
! scope="row"| 4
−
| Geographical Controller
+
|
 +
10/18/2014
 +
|
 +
11/4/2014
 +
|
 +
Parse GPS data and setup constructs to send appropriate data
 +
|
 +
Finished
 +
|
 +
11/1/2014
 
|-
 
|-
−
| 0x05
+
! scope="row"| 5
−
| IO Controller
+
|
 +
10/14/2014
 +
|
 +
10/18/2014
 +
|
 +
Interface the Compass Module
 +
|
 +
Finished
 +
|
 +
10/16/2014
 
|-
 
|-
−
| 0x06
+
! scope="row"| 6
−
| Bridge Controller
+
|
−
|}
+
10/25/2014
−
 
+
|
−
{| class="wikitable"
+
11/4/2014
−
|+ Common Communication Table
+
|
 +
Calibration of Compass
 +
|
 +
Finished
 +
|
 +
11/1/2014
 
|-
 
|-
−
| Message Number
+
! scope="row"| 7
−
| Purpose / Data layout
+
|
 +
11/4/2014
 +
|
 +
11/11/2014
 +
|
 +
Integrate GPS and Compass data
 +
|
 +
Finished
 +
|
 +
11/4/2014
 
|-
 
|-
−
| 0x101
+
! scope="row"| 8
−
| Get version and boot info
+
|
 +
10/25/2014
 +
|
 +
11/30/2014
 +
|
 +
Testing and mapping of GPS co-ordinates
 +
|
 +
Finished
 +
|
 +
11/20/2014
 
|-
 
|-
−
| 0x102
+
! scope="row"| 9
−
| Get general info
+
|
−
|-
+
11/18/2014
−
| 0x103
+
|
−
| Synchronize (set) time:
+
12/18/2014
−
byte [0-3] : System time
+
|
−
|-
+
Final integration and testing
−
| 0x201
+
|
−
|  
+
Finished
−
byte [0-3] : Version Info
+
|
−
byte [4-7] : boot timestamp
+
12/15/2014
−
|-
+
|}
−
| 0x202
+
 
−
|
+
==== Hardware Design ====
−
byte [0-3] : Current time
+
[[File:CmpE243_F14_T3_HWDesign.png]]
−
byte [4]  : CPU usage %
+
 
−
|}
+
==== Hardware Interface ====
  
 
{| class="wikitable"
 
{| class="wikitable"
−
|+ Subscription Rate Info
+
|+ Geographical Controller Pin Connectivity Table
 
|-
 
|-
−
| Byte 0
+
! scope="col"| '''Description'''
−
| Effect
+
! scope="col"| '''Your Device Port'''
 +
! scope="col"| '''SJOne Development Board Port'''
 
|-
 
|-
−
| 0
+
| Supply Voltage
−
| Off
+
| Vcc
 +
| 3v3
 
|-
 
|-
−
| 1
+
| Ground
−
| 1Hz
+
| GND
 +
| GND
 
|-
 
|-
−
| 5
+
| GPS Module
−
| 5Hz
+
|
 +
Channel 1 -> Rx, Channel 2 -> Tx
 +
|
 +
Channel 1-> Tx P2.8, Channel 2-> Rx P2.9
 
|-
 
|-
−
| 10
+
| Compass
−
| 10Hz
+
|
 +
SCL
 +
SDA
 +
|  
 +
SCL2 -> P0.11
 +
SDA2 -> P0.10
 
|-
 
|-
−
| 20
+
| CAN Transceiver
−
| 20Hz
+
|
−
|-
+
Pin no. 1 Driver Input
−
| 50
+
Pin no. 4 Receiver Output
−
| 50Hz
+
|
 +
P0.1 CAN TD1
 +
P0.0 CAN RD1
 
|-
 
|-
−
| Any other value
 
−
| Invalid date rate
 
 
|}
 
|}
  
 +
==== Software Design ====
 +
[[File:CmpE243 F14 Team3OP GPS Module Software Top.jpeg||800px||Top level view of GPS software flow]]
 +
<br>
 +
 +
The figure above shows a top level view of the geographical team's software flow. The main message task, shown in the middle, is responsible for handling and updating the CAN message pointer. The CAN message pointer is read and handled in a separate periodic task that runs and sends messages across the CAN bus at frequencies of 1, 5, 10 or 20 Hz.
 +
 +
The GPS and compass tasks, shown on the left and right respectively, collect their respective data and send that data to the message task. The message task will grab this data and stuff the CAN message variable to be sent to the Master module.
 +
 +
[[File:CmpE243 F14 TeamUndergrad GPS GPS.jpeg||600px]]
 +
[[File:CmpE243 F14 TeamUndergrad GPS compass.jpeg||600px]]
 +
<br>
 +
''GPS''<br>
 +
NMEA (National Marine Electronics Association)<br>
 +
*NMEA consists of sentences, the first word of which, called a data type, defines the interpretation of the rest of the sentence. <br>
 +
*Each Data type would have its own unique interpretation and is defined in the NMEA standard.<br>
 +
*In our project we are using RMC (Recommended Minimum GPS data).Below is an example of RMC data.<br>
 +
 +
$GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A
 +
 +
Where:
 +
    RMC          Recommended Minimum sentence C
 +
    123519      Fix taken at 12:35:19 UTC
 +
    A            Status A=active or V=Void.
 +
    4807.038,N  Latitude 48 deg 07.038' N
 +
    01131.000,E  Longitude 11 deg 31.000' E
 +
    022.4        Speed over the ground in knots
 +
    084.4        Track angle in degrees True
 +
    230394      Date - 23rd of March 1994
 +
    003.1,W      Magnetic Variation
 +
    *6A          The checksum data, always begins with *
 +
 +
 +
Connection and Software Flow GPS:
 +
 +
SJone board and GPS module is connected using UART.
 +
At boot-up GPS tries to get fix for all possible satellites to get proper GPS values.
 +
 +
''Compass''<br>
 +
The Compass works over the I2C bus interface. Based on the datasheet, the compass will send data when it receives a 'A' command.
 +
 +
==== Implementation ====
  
 
{| class="wikitable"
 
{| class="wikitable"
−
|+ Master Controller Communication Table
+
|+ GPS Controller Communication Table
 
|-
 
|-
 
| Message Number
 
| Message Number
 
| Purpose
 
| Purpose
−
| Data Byte Pattern
+
| Data layout
 
|-
 
|-
−
| 0x101
+
| 0x518
−
| Ask for Boot and Version Info. of all Controllers
+
| Send GPS Data to Master
−
|  
+
|
−
Byte[0]: Send a '1'
+
  byte [0] : New Degree
−
|
+
  byte [1] : Distance
−
|-
+
  byte [2] : Current Degree
−
| 0x103
 
−
| Sync. Master System Time on all Controllers
 
−
|
 
−
Byte[0-3]: System Time [HH:MM:SS]
 
−
|
 
 
|-
 
|-
−
| 0x201
+
| 0x519
−
| Master Gets Status Update from all controllers
+
| Send GPS FIX ACK to Master
−
|
+
|
−
Byte[0]: Boot Status
+
  byte[0]: Send a '1'
−
Byte[1]: Version Info.
 
−
|
 
 
|-
 
|-
−
| 0x203
+
| 0x52A
−
| Master Gets current Time from all Controllers
+
| Send Destination Reached ACK to master
−
|
+
|
−
Byte[0-3]: Time in [HH:MM:SS]
+
  byte[0]: Send a '1'
−
|
 
 
|-
 
|-
−
| 0x301
+
|}
−
| Master Enable Main UI in Android
+
 
−
|
+
==== Testing and Technical Challenge ====
−
  Byte[0]: Send a '1'
+
*Geographical Controller
−
|
+
**GPS
 +
***GPS data was relatively straightforward to receive, however we ran into quite a few issues trying to parse the data.
 +
***Often times we would read the UART data in the middle of the buffer being changes to the next data point, for example, the reading would look like this:
 +
****$GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4$GPRMC,123519,A,4807.038
 +
****Instead of the normal data point: $GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A
 +
***By checking the Checksum at the end of the string, *6A, we were able to determine the number of characters that were supposed to be in the string and exclude any strings that did not have the correct number of characters.
 +
**Compass
 +
***The Compass data was also straight forward to get. The compass HMC6352 has many useful features as provided in the datasheet, We focused on using the basic output data mode with heading mode.
 +
***The Compass is very sensitive to any kind of magnetic interference. In our project it were the motors and we had to make sure we mount the compass as far as possible from the motors to avoid any interference even though we had the calibration mode set up.
 +
***Sometimes the SDA and SCL used to get short (not because of hardware problem) maybe due to line impedance or parasitic capacitance since the wires were close to each other. A software reset can solve the problem.
 +
 
 +
== '''Android & Communication Bridge Controller''' ==
 +
==== Group Members ====
 +
'''''Chia-Pin Tseng (Ben)'''''
 +
'''''Johnny Yam'''''
 +
  '''''Kevin Beadle'''''
 +
 
 +
==== Communication Bridge & Android Team Schedule ====
 +
 
 +
{| class="wikitable"
 
|-
 
|-
−
| 0x302
+
! scope="col"| Sl.No
−
| Master set GPS Destination on Geo Controller
+
! scope="col"| Start Date
−
|
+
! scope="col"| Planned End Date
−
Byte[0-3]: Latitude Value
+
! scope="col"| Task
−
Byte[4-7]: Longitude Value
+
! scope="col"| Status
−
|
+
! scope="col"| Actual End Date
 
|-
 
|-
−
| 0x303
+
! scope="row"| 1
−
| Master set Longitude Way-Points on Geo
+
| 9/30/2014
−
|
+
| 9/30/2014
−
bytes [0-1] : Total Way-Points count
+
| Obtain Bluetooth Module (already had one)
−
bytes [2-3] : Way-Point index
+
| Done
−
bytes [4-7] : Longitude(float)
+
| 9/30/2014
−
|
 
 
|-
 
|-
−
| 0x304
+
! scope="row"| 2
−
| Master set Latitude Way-Points on Geo
+
| 9/30/2014
−
|
+
| 10/14/2014
−
bytes [0-1] : Total Way-Points count
+
| Develop Basic Android App with Bluetooth Sensor Communication
−
bytes [2-3] : Way-Point index
+
| Done
−
bytes [4-7] : Latitude(float)
+
| 10/7/2014
−
|
 
 
|-
 
|-
−
| 0x305
+
! scope="row"| 3
−
| Master Send GPS FIX Ack to Bridge
+
| 10/11/2014
−
|
+
| 10/14/2014
−
Byte[0]: Send a value '1'
+
| Interface Bluetooth Module with SJSU Dev Board
−
|
+
| Done
 +
| 10/11/2014
 
|-
 
|-
−
| 0x306
+
! scope="row"| 4
−
| Master Send Dest. Reached Ack to Bridge
+
| 10/12/2014
−
|
+
| 10/19/2014
−
Byte[0]: Send a Value '1'
+
| Be able to send bi-directional arbitrary messages between Android App and Dev Board via Bluetooth
−
|
+
| Done
 +
| 10/14/2014
 
|-
 
|-
−
| 0x500
+
! scope="row"| 5
−
| Display Boot and Version Info. on LCD
+
| 10/14/2014
−
|
+
| 11/21/2014
−
Byte[0]: Boot Status Response
+
| Subscribe to all CAN messages and dump all of them via Bluetooth to Android App or web interface
−
Byte[1]: Version Info.
+
| Done
−
|
+
| 11/24/2014
 
|-
 
|-
−
| 0x501
+
! scope="row"| 6
−
| Display Controllers Time on LCD
+
| 10/14/2014
−
|
+
| 11/21/2014
−
Byte[0-3]: Time in [HH:MM:SS]
+
| Ajax & Websocket server remote structure
−
|
+
| Done
 +
| 11/01/2014
 
|-
 
|-
−
| 0x502
+
! scope="row"| 7
−
| Display Destination Has Reached
+
| 10/14/2014
−
|
+
| 11/21/2014
−
Byte[0]: Send a '1'
+
| Be able to input GPS coordinates through either (or both) Android App and web interface and send through Bluetooth then CAN bus
−
|
+
| Done
 +
| 11/24/2014
 
|-
 
|-
−
| 0x503
+
! scope="row"| 8
−
| Master Set Speed and Direction of Motor
+
| 10/21/2014
−
|
+
| 11/24/2014
−
Byte[0]: LEFT/RIGHT (or) FRONT/BACK command
+
| Android App and webpage GUI enhancements (Google Maps, Google Drive)
−
|
+
| Done
 +
| 11/24/2014
 
|-
 
|-
−
| 0x504
+
! scope="row"| 9
−
| Display Speed of Motor on LCD
+
| 10/21/2014
−
|
+
| 11/30/2014
−
Byte[0]: Speed Value
+
| Data visualization (status, compass, speed, location,....)
−
|
+
| Done
−
|-
+
| 11/30/2014
−
| 0x505
+
|}
−
| Display GPS and Compass values on LCD
 
−
|
 
−
Byte[0-1]: New Degree to Head
 
−
Byte[2-3]: Dist to Destination
 
−
Byte[4-5]: Current Degree value
 
−
|
 
−
|-
 
−
|0x506
 
−
| Display Sensor Values on LCD
 
−
|
 
−
Byte [0]: Front sensor value in inches
 
−
Byte [1]: Front Left sensor value in inches
 
−
Byte [2]: Front Right sensor value in inches
 
−
Byte [3]: Back sensor value in inches
 
−
|
 
−
|-
 
−
|0x507
 
−
| Display Battery Status on LCD
 
−
|
 
−
Byte[0]: Battery Status Value
 
−
|
 
−
|-
 
−
|}
 
  
 +
==== Hardware Design ====
 +
[[File:bbee_LRG.jpg|300px|thumb|right|Bluetooth Bee Module]]
 +
*In order to facilitate wireless communication between the SJSU One Board and a Android device, a Bluetooth Bee module is used. This module was chosen because it can connect and mount directly onto the SJSU One Board's XBee breakout socket.
 +
*The Bluetooth Bee is a Serial Profile Port (SPP) Bluetooth interface that connects with the SJSU development board's UART3.
  
 +
==== Hardware Interface ====
 +
The relevant pin connectivity table between the Bluetooth Bee module and the SJSU One Development Board is shown below:
 
{| class="wikitable"
 
{| class="wikitable"
−
|+ Motor Controller Communication Table
+
|+ Communication Bridge Pin Connectivity Table
 
|-
 
|-
−
| Message Number
+
| Description
−
| Purpose
+
| Bluetooth Bee Port
−
| Data layout
+
| SJSU Development Board Port
 +
| CAN Transceiver
 
|-
 
|-
−
| 0x508
+
| 3.3V Supply Voltage
−
| Speed Sensor Data
+
| 3V3
−
|
+
| 3V3
−
byte [0] : Speed sensor value in rpm
+
| 3V3
−
|-
 
−
| 0x509
 
−
| Vehicle Direction/Movement Data
 
−
|
 
−
byte [0] : Movement Control
 
−
      0x1 : Forward
 
−
      0x2 : Reverse
 
−
      0x3 : Stop
 
−
byte [1] : Steering Control
 
−
      0x1 : Left
 
−
      0x2 : Right
 
−
      0x3 : Straight
 
 
|-
 
|-
−
|}
+
| Ground
−
 
+
| GND
−
 
+
| GND
−
{| class="wikitable"
+
| GND
−
|+ Sensor Controller Communication Table
 
 
|-
 
|-
−
| Message Number
+
| UART Channel 1
−
| Purpose
+
| TX
−
| Data layout
+
| RX
 +
|
 
|-
 
|-
−
| 0x510
+
| UART Channel 2
−
| Front/Back Range Sensor Data
+
| RX
 +
| TX
 
|
 
|
−
byte [0] : Front sensor value in inches
+
|-
−
byte [1] : Front Left sensor value in inches
+
| CAN TXD
−
byte [2] : Front Right sensor value in inches
+
|
−
byte [3] : Back sensor value in inches
+
| CAN TD1
−
|-  
+
| TXD
−
| 0x511
+
|-
−
| Accelerometer/Light/Battery Sensor Data
+
| CAN RXD
−
|
+
|  
−
byte [0] : X axis Value
+
| CAN RD1
−
byte [1] : Y axis Value
+
| RXD
−
byte [2] : Z axis Value
+
|-
−
byte [3] : Light sensor value
 
−
byte [4] : Battery status value
 
−
|-  
 
 
|}
 
|}
  
 +
The Bluetooth Bee Module interfaces with an Android device through Bluetooth. In addition, various commands and data are then sent and received to and from the CAN bus through the Bluetooth Module to the Android device.
  
−
{| class="wikitable"
+
==== Software Design ====
−
|+ GPS Controller Communication Table
+
*The bridge controller and Android APP work as routers
−
|-
+
 
−
| Message Number
+
''Bridge Controller ''
−
| Purpose
+
*Bridge controller translates CAN bus data into plain text and send it to android platform
−
| Data layout
+
*The Bridge controller is comprised of the SJSU Development Board with the Bluetooth Bee Module.
−
|-
+
*The Bluetooth Bee Module can be configured by writing to UART3 specific commands as specified in the [http://www.seeedstudio.com/wiki/Bluetooth_Bee Bluetooth Bee Seeedstudio Wiki].
−
| 0x518
+
*The Bluetooth Bee Module was configured as SLAVE MODE via the command: ''\r\n+STWMOD=0\r\n'' (The Android device will act as the Bluetooth Master)
−
| Send GPS Data to Master
+
*The Bluetooth device name was set to "Yam_BluetoothBee" using the command: ''\r\n+STNA=Yam_BluetoothBee\r\n''
−
| 
+
*Allowing other devices to connect to the Bluetooth Module was enabled using the command: ''\r\n+STOAUT=1\r\n''
−
  byte [0] : New Degree
+
*Finally the Bluetooth Bee Module started broadcasting/inquiring to connect to another device using the command: ''\r\n+INQ=1\r\n''
−
  byte [1] : Distance
+
*There are many other commands, such as to change the default pincode value, but they were not used for this project.
−
  byte [2] : Current Degree
+
 
−
|-
+
 
−
| 0x519
+
{| style="width:800px;" |
−
| Send GPS FIX ACK to Master
+
|[[File:CmpE243_F14_T3_Bridge_flow_Dia.png|700px|thumb|left|Bridge framework ]]
−
| 
 
−
  byte[0]: Send a '1'
 
−
|-
 
−
| 0x52A
 
−
| Send Destination Reached ACK to master
 
−
|
 
−
  byte[0]: Send a '1'
 
−
|-
 
 
|}
 
|}
  
 +
The architecture for our bridge controller is to interconvert the data between Bluetooth message and CAN bus message.
 +
Bluetooth message uses simple plaintext to transfer data. However, before we can deal with the string data, to collect and assemble several bytes into a package is needed, because UART is byte based data transmission. I use a byte 0x13(which is ‘\r’ in C code) at the end byte.The bluetooth sender must send 0x13 in the end of every text message. This process is achieved by BluBeeTask_BT2CAN class.
 +
CAN bus message uses 29bits as message ID and 8bytes data length as a single package to communicate with the master controller.
 +
There are two main classes for the controller. BluBeeTask_BT2CAN and BluBeeTask_CAN2BT.
  
−
{| class="wikitable"
+
*BluBeeTask_BT2CAN
−
|+ IO Communication Table
+
BluBeeTask_BT2CAN is responsible for receiving the data which comes from bluetooth(via UART).We can setup multiple message filters to receive and process certain message data.
−
|-
+
 
−
| Message Number
+
Filter setting format.
−
| Purpose
+
    blutoothReceiverTask->addCMD(
−
| Data layout
+
    BluBeeTask_BT2CAN::CMDProp::gen((char* cmd,
−
|-
+
                bool (*func)(BluBeeTask_BT2CAN *, char* CMDStr)));
−
| 0x520
+
 
−
| Subscribe to Sensor data
+
For example, there is a message format “Speed<data>” to control the speed of the automatic car. We can simply apply a filter as below
−
| bytes [0-5] : Sensor Value in Inches
+
 
−
|-
+
    blutoothReceiverTask->addCMD(
−
| 0x521
+
    BluBeeTask_BT2CAN::CMDProp::gen("Speed", SpeedCMD));
−
| Subscribe to Motor data
+
 
−
| bytes [0-2] : Vehicle Direction
+
 
−
|-
+
then, we have a callback function “SpeedCMD” that can only receive speed setting messages.(For instance there is a message “Speed23” was sent by Android)
−
| 0x522
+
 
−
| Subscribe to Compass Data
+
    bool SpeedCMD(BluBeeTask_BT2CAN *sender, char* CMDStr)//CMDStr will be “23”
−
| bytes [0] : Compass Data in degrees
+
    {
−
|-
+
        int speed = 0;
−
| 0x523
+
        CMDStr=parseInt(CMDStr,&speed);//parse string “23” into integer 23
−
| Subscribe to Battery Status
+
        can_msg_t msg = { 0 };//CAN message
−
| bytes [0] : Battery Status Value
+
        msg.msg_id = make_id(cid_master_controller, CAN_TX_CAR_SPEED_MSG_ID);
−
|-
+
        //Set the ID to send to master controller with speed message ID
−
|}
+
        *(int *) &(msg.data.bytes[0]) = speed;//First byte is the speed 23
 +
        return sender->Send2CAN(msg);//Send message via CAN bus
 +
    }
 +
You can see the call back function SpeedCMD is doing a very simple string processing, then, send it to the master controller via CAN bus.
 +
 
 +
*BluBeeTask_CAN2BT
 +
What BluBeeTask_CAN2BT doing is actually very similar to BluBeeTask_BT2CAN. First, you need to apply CAN message filters and set the corresponding callback functions.
 +
 
 +
Filter setting format.
 +
    CANReceiverTask->addMsgTamp(
 +
            BluBeeTask_CAN2BT::MsgProp::gen(
 +
                  (controller_id_t MsgIdTmp, controller_id_t Mask,
 +
            bool (*func)(BluBeeTask_CAN2BT *, can_msg_t Msg)));
 +
 
 +
controller_id_t is the set of information of CAN message ID including source, destination, and message number. To setup a controller_id_t variable you can simply use a function make_id.
 +
 
 +
    controller_id_t ID= make_id(destination,source,message Number);
 +
 
 +
MsgIdTmp is the message ID that you wanna receive. Bit 1 in mask means that certain bit you need to compare between MsgIdTmp and received message ID.
  
  
 
{| class="wikitable"
 
{| class="wikitable"
−
|+ Communication Bridge Communication Table
+
|+ CAN message mask example
 
|-
 
|-
−
| Message Number
 
−
| Purpose
 
−
| Data layout
 
−
|-
 
−
| 0x528
 
−
| Set Car Speed (Kill Switch) - temporary allow for other non-zero value for demo
 
−
| byte[0] - speed value
 
−
|-
 
−
| 0x529
 
−
| Destination GPS location
 
 
|
 
|
−
bytes [0-3] : latitude (float)
+
received message ID
−
bytes [4-7] : longitude (float)
+
−
|-
+
[00,12,07]
−
| 0x52A
+
 
−
| Turn to degree
+
MsgIdTmp
−
|
+
 
−
bytes [0-3] : degree(float)
+
[20,12,31]
−
|-
+
 
−
| 0x52B
+
Mask
−
| Way points longitude
+
 
−
|
+
[00,FF,00]
−
bytes [0-1] :total waypoints count
+
 
−
bytes [2-3] :waypoint index
+
Success
−
bytes [4-7] : longitude(float)
+
 
−
|-
+
First mask data 00 means ignore the first data difference between received message ID and MsgIdTmp(ignore 00!=20).
−
| 0x52C
+
 
−
| Way points latitude
+
Second mask data FF means you need to compare the second data. In this case both are 12, therefore, it passes the comparison
−
|
+
 
−
bytes [0-1] :total waypoints count
+
Third mask data is 00 (ignore 07!=20).
−
bytes [2-3] :waypoint index
+
|
−
bytes [4-7] : latitude(float)
+
received message ID
−
|-
+
 
−
| 0x52D
+
[00,12,07]
−
| remote status (ie. Android connection status)
+
 
−
|
+
MsgIdTmp
−
bytes [0]=>
+
 
−
0:disconnected(passive send)
+
[20,12,31]
−
1:on disconnect(active)
+
 
−
2:connected(passive)
+
Mask
−
3:on connect(active)
+
 
−
0xFF:error(active/passive)
+
[00,FF,FF]
−
|-
+
 
 +
Failed
 +
 
 +
Third mask data is FF, so we need to compare 07 and 31. Apparently, 07 is not equal to 31, so the comparison is failed.
 
|}
 
|}
  
−
=== Pin Connectivity Table ===
 
  
 +
For example, there is a compass message comes from master. We can simply apply a filter as below
 +
 +
    can2btptr->addMsgTamp(
 +
            BluBeeTask_CAN2BT::MsgProp::gen(
 +
                    make_id(0, cid_master_controller,
 +
                            CAN_RX_DA_COMPASSSTATUS_MSG_ID), //Message ID templete
 +
                    make_id(0,0xFFF,0xFFF)//Mask means don’t compare source section
 +
                    , compassMSG));//Set Callback function compassMSG
 +
 +
We have a callback function “compassMSG” that can only receive compass messages and whichmessage was come from master controller. Since bridge controller receive this information, so we don’t need to compare destination.
 +
 +
  bool compassMSG(BluBeeTask_CAN2BT *canbt, can_msg_t Msg)
 +
  {
 +
      sprintf(STRBUFF, "geo::%d,%d,%d,%d\r", (int16_t) Msg.data.words[0],
 +
            (int16_t) Msg.data.words[1], (int16_t) Msg.data.words[2],
 +
            (int16_t) Msg.data.words[3]);
 +
      //convert those data into a string
 +
      //notice the end of the string is ‘\r’, which is needed
 +
      canbt->Send2BT(STRBUFF);// send to UART(Bluetooth)
 +
      return true;
 +
  }
 +
 +
 +
''Android Controller ''
 +
*Android platform receives the text data from bridge controller, then, transmit the data through ajax or websocket
 +
*External controller could be any TCP accessible device (simple pebble watch program (20 lines) are used to control start and stop)
 +
*One administrator(control and receive), multiple observers(only receive)
 +
*Number of way points and routing is dynamically determined and done using the Google Maps API
 +
 +
 +
{| style="width:800px;" |
 +
|[[File:CmpE243_F14_T3_bridge_framework.png|400px|thumb|left|Bridge framework ]]
 +
|[[File:CmpE243 F14 T3 bridge cross.png|800px|thumb|left|cross platform ]]
 +
|}
 +
 +
 +
{| style="width:800px;" |
 +
|[[File:CmpE243_F14_T3_Android_Intro.png|200px|thumb|left|Intro]]
 +
|[[File:CmpE243_F14_T3_Android_Menu.png|200px|thumb|left|Intro]]
 +
|[[File:CmpE243_F14_T3_Android_OverView.png|200px|thumb|left|Intro]]
 +
|[[File:CmpE243_F14_T3_Android_Map.png|200px|thumb|left|Intro]]
 +
|}
 +
<BR/>
 +
 +
==== Implementation ====
 
{| class="wikitable"
 
{| class="wikitable"
−
|+ Sensor Controller Pin Connectivity Table
+
|+ Communication Bridge Communication Table
 
|-
 
|-
−
! scope="col"| '''Description'''
+
| Message Number
−
! scope="col"| '''Your Device Port'''
+
| Purpose
−
! scope="col"| '''SJOne Development Board Port'''
+
| Data layout
−
! scope="col"| '''Commands'''
+
|-
−
! scope="col"| '''Note'''
+
| 0x528
 +
| Set Car Speed (Kill Switch) - temporary allow for other non-zero value for demo
 +
| byte[0] - speed value
 
|-
 
|-
−
| Supply Voltage
+
| 0x529
−
|
+
| Destination GPS location
−
| 
 
−
|  
 
 
|
 
|
 +
bytes [0-3] : latitude (float)
 +
bytes [4-7] : longitude (float)
 
|-
 
|-
−
| Ground
+
| 0x52A
−
|  
+
| Turn to degree
−
| GND
 
 
|
 
|
−
|
+
bytes [0-3] : degree(float)
 
|-
 
|-
−
| Sonar Sensor
+
| 0x52B
−
|
+
| Way points longitude
−
|
 
−
|
 
−
|
 
−
|-
 
−
| IR Sensor
 
−
|
 
−
|  
 
 
|
 
|
 +
bytes [0-1] :total waypoints count
 +
bytes [2-3] :waypoint index
 +
bytes [4-7] : longitude(float)
 +
|-
 +
| 0x52C
 +
| Way points latitude
 
|
 
|
 +
bytes [0-1] :total waypoints count
 +
bytes [2-3] :waypoint index
 +
bytes [4-7] : latitude(float)
 
|-
 
|-
−
| CAN Transceiver
+
| 0x52D
−
| Pin no. 1 Driver Input
+
| remote status (ie. Android connection status)
−
Pin no. 4 Receiver Output
 
−
| P0.1 CAN TD1
 
−
P0.0 CAN RD1
 
 
|
 
|
−
|
+
bytes [0]=>
 +
0:disconnected(passive send)
 +
1:on disconnect(active)
 +
2:connected(passive)
 +
3:on connect(active)
 +
0xFF:error(active/passive)
 
|-
 
|-
 
|}
 
|}
  
−
 
+
==== Testing and Technical Challenge ====
 +
''TESTs''
 +
*100000 message(20bytes per message) Bluetooth transmission between board and android under 200fps with range <5m
 +
**100% success
 +
 
 +
''ISSUE''
 +
*3G network server could not be access(3G network is used for long range communication)
 +
**might use google sheet or external server to communicate
 +
 
 +
== '''I/O Unit Controller''' ==
 +
==== Group Members ====
 +
'''''Shreeram Gopalakrishnan'''''
 +
'''''Sreeharsha Paturu Gangadhara'''''
 +
==== IO Team Schedule ====
 +
 
 
{| class="wikitable"
 
{| class="wikitable"
−
|+ Motor Controller Pin Connectivity Table
 
 
|-
 
|-
−
! scope="col"| '''Description'''
+
! scope="col"| Sl.No
−
! scope="col"| '''Your Device Port'''
+
! scope="col"| Start Date
−
! scope="col"| '''SJOne Development Board Port'''
+
! scope="col"| End Date
−
! scope="col"| '''Commands'''
+
! scope="col"| Task
−
! scope="col"| '''Note'''
+
! scope="col"| Status
 +
! scope="col"| Actual Completion Date
 
|-
 
|-
−
| Supply Voltage
+
! scope="row"| 1
−
| 6V from NiMH battery
+
| 10/7/2014
−
| N/A
+
| 10/13/2014
−
|  
+
| Research and Order LCD Display
−
|
+
| Ordered LCD Display
 +
| 10/13/2014
 
|-
 
|-
−
| Ground
+
! scope="row"| 2
−
| GND (Black Wire)
+
| 10/14/2014
−
| GND
+
| 10/21/2014
−
|  
+
| Interfacing LCD Display with LPC1758
−
|
+
| Completed
 +
| 10/21/2014
 
|-
 
|-
−
| ESC
+
! scope="row"| 3
−
|
+
| 10/21/2014
−
  Control (White Wire)
+
| 10/28/2014
−
|
+
| Implementing CAN structure with LCD tasks.
−
  P2.0 PWM
+
| Completed
−
|
+
| 11/30/2014
−
  PWM motor(PWM::''pwm1'', 101);
 
−
  motor.set(14.5);
 
−
|
 
−
  Sets PWM signal of 101 Hz
 
−
  Sets duty cycle of 14.5% for forward movement
 
 
|-
 
|-
−
| Servo
+
! scope="row"| 4
−
|
+
| 10/28/2014
−
  Control (White Wire)
+
| 11/04/2014
−
|
+
| Subscribe data from sensor and GPS controller,display it on LCD.
−
  P2.1 PWM
+
| Completed
−
|
+
| 11/08/2014
−
  PWM servo(PWM::''pwm2'', 101);
 
−
  servo.set(15);
 
−
|
 
−
  Sets PWM signal of 101 Hz
 
−
  Sets duty cycle of 15% for no turn
 
 
|-
 
|-
−
| CAN Transceiver
+
! scope="row"| 5
−
|
+
| 11/04/2014
−
  Pin no. 1 Driver Input
+
| 11/11/2014
−
  Pin no. 4 Receiver Output
+
| Setup hardware and write code for START, STOP and Headlight buttons.
−
|
+
| Completed
−
  P0.1 CAN TD1
+
| 11/12/2014
−
  P0.0 CAN RD1
+
|-
−
|
+
! scope="row"| 6
−
|
+
| 11/11/2014
−
  TI CAN Transceiver SN65HVD232D
+
| 11/18/2014
−
  Pin 7 - CAN H & Pin 6 - CAN L
+
| Testing and mounting hardware on car.
 +
| Completed
 +
| 11/27/2014
 
|-
 
|-
 +
! scope="row"| 7
 +
| 11/18/2014
 +
| 11/25/2014
 +
| Final Testing
 +
| Completed
 +
| 12/15/2014
 
|}
 
|}
  
−
 
+
==== Hardware Design ====
−
{| class="wikitable"
+
*The IO Control Unit manages the LCD Display, switch to start and stop the car
 +
*It receives CAN data from the Master controller and accordingly processes to display on the LCD through UART
 +
* The 7 segment LED displays the CPU usage
 +
''LCD Display ''
 +
*The LCD Display is placed on the rear side of our RC Car
 +
*It displays the sensor and GPS values in real time.
 +
[[File: CmpE243_F14_T3_LCD_values.JPG|500px]]
 +
 
 +
==== Hardware Interface ====
 +
{| style="width:800px;" |
 +
|[[File:CmpE243_F14_T3_IO_Interface.JPG|700px|thumb|left|LCD hardware interface]]
 +
|}
 +
 
 +
{| class="wikitable"
 
|+ I/O Controller Pin Connectivity Table
 
|+ I/O Controller Pin Connectivity Table
 
|-
 
|-
Line 1,590: Line 1,866:
 
|}
 
|}
  
 +
==== Software Design ====
 +
{|
 +
[[File:LCD.jpg|400px|thumb|left|LCD Software Interface ]]
 +
|}
 +
<BR/>
 +
<BR/>
 +
<BR/>
 +
<BR/>
 +
<BR/>
 +
<BR/>
 +
<BR/>
 +
<BR/>
 +
<BR/>
 +
<BR/>
 +
<BR/>
 +
<BR/>
 +
<BR/>
 +
<BR/>
  
 +
==== Implementation ====
 +
|[[File:cmpe243.team3.IO_FLOW.jpg‎|500px]]
 
{| class="wikitable"
 
{| class="wikitable"
−
|+ Geographical Controller Pin Connectivity Table
+
|+ IO Communication Table
 
|-
 
|-
−
! scope="col"| '''Description'''
+
| Message Number
−
! scope="col"| '''Your Device Port'''
+
| Purpose
−
! scope="col"| '''SJOne Development Board Port'''
+
| Data layout
−
! scope="col"| '''Commands'''
 
−
! scope="col"| '''Note'''
 
 
|-
 
|-
−
| Supply Voltage
+
| 0x102
−
| Vcc
+
| Send boot status and version info
−
| 3v3
+
| bytes [0-2] : Status and version info
−
|  
 
−
|
 
 
|-
 
|-
−
| Ground
+
| 0x505
−
| GND
+
| Display GPS and compass values
−
| GND
 
 
|
 
|
−
|
+
Byte[0-1]: New Degree to Head
 +
Byte[2-3]: Dist to Destination
 +
Byte[4-5]: Current Degree value
 
|-
 
|-
−
| GPS Module
+
| 0x506
−
|
+
| Display Sensor Values
−
Channel 1 -> Rx, Channel 2 -> Tx
 
−
|
 
−
Channel 1-> Tx P2.8, Channel 2-> Rx P2.9
 
−
|  
 
 
|
 
|
−
|-
+
  Byte [0]: Front sensor value in inches
−
| Compass
+
  Byte [1]: Front Left sensor value in inches
−
|
+
  Byte [2]: Front Right sensor value in inches
−
  SCL
+
  Byte [3]: Back sensor value in inches
−
  SDA
+
  Byte [4]: Speed value
−
|
 
−
  SCL2 -> P0.11
 
−
  SDA2 -> P0.10
 
−
|
 
−
|
 
−
|-
 
−
| CAN Transceiver
 
−
|
 
−
  Pin no. 1 Driver Input
 
−
Pin no. 4 Receiver Output
 
−
|
 
−
P0.1 CAN TD1
 
−
P0.0 CAN RD1
 
−
|
 
−
|
 
 
|-
 
|-
 
|}
 
|}
  
−
 
+
==== Testing and Technical Challenge ====
−
{| class="wikitable"
+
{| style="width:800px;" |
−
|+ Master Controller Pin Connectivity Table
+
|[[File:CmpE243_F14_T3_LCD_error.jpg|700px|thumb|left|LCD junk values]]
−
|-
 
−
! scope="col"| '''Description'''
 
−
! scope="col"| '''Your Device Port'''
 
−
! scope="col"| '''SJOne Development Board Port'''
 
−
! scope="col"| '''Commands'''
 
−
! scope="col"| '''Note'''
 
−
|-
 
−
| Supply Voltage
 
−
|
 
−
| 
 
−
|
 
−
|
 
−
|-
 
−
| Ground
 
−
|
 
−
| GND
 
−
|
 
−
|
 
−
|-
 
−
| CAN Transceiver
 
−
| Pin no. 1 Driver Input
 
−
Pin no. 4 Receiver Output
 
−
| P0.1 CAN TD1
 
−
P0.0 CAN RD1
 
−
|
 
−
|
 
−
|-
 
−
|}
 
−
 
 
−
 
 
−
{| class="wikitable"
 
−
|+ Communication Bridge Pin Connectivity Table
 
−
|-
 
−
| Description
 
−
| Bluetooth Bee Port
 
−
| SJSU Development Board Port
 
−
| CAN Transceiver
 
−
|-
 
−
| 3.3V Supply Voltage
 
−
| 3V3
 
−
| 3V3
 
−
| 3V2
 
−
|-
 
−
| Ground
 
−
| GND
 
−
| GND
 
−
| GND
 
−
|-
 
−
| UART Channel 1
 
−
| TX
 
−
| RX
 
−
|
 
−
|-
 
−
| UART Channel 2
 
−
| RX
 
−
| TX
 
−
|
 
−
|-
 
−
| CAN TXD
 
−
|
 
−
| CAN TD1
 
−
| TXD
 
−
|-
 
−
| CAN RXD
 
−
|
 
−
| CAN RD1
 
−
| RXD
 
−
|-
 
−
|}
 
−
 
 
−
=== Communication Bridge + Android ===
 
−
 
 
−
==== Hardware Design ====
 
−
*In order to facilitate wireless communication between the SJSU One Board and a Android device, a Bluetooth Bee module is used. This module was chosen because it can connect and mount directly onto the SJSU One Board's XBee breakout socket.
 
−
*The Bluetooth Bee is a Serial Profile Port (SPP) Bluetooth interface that connects with the SJSU development board's UART3.
 
−
{| style="width:300px;" |
 
−
|[[File:bbee_LRG.jpg|300px|thumb|left|Bluetooth Bee Module]]
 
−
|}
 
−
 
 
−
==== Hardware Interface ====
 
−
The relevant pin connectivity table between the Bluetooth Bee module and the SJSU One Development Board is shown below:
 
−
{| class="wikitable"
 
−
|+ Communication Bridge Pin Connectivity Table
 
−
|-
 
−
| Description
 
−
| Bluetooth Bee Port
 
−
| SJSU Development Board Port
 
−
| CAN Transceiver
 
−
|-
 
−
| 3.3V Supply Voltage
 
−
| 3V3
 
−
| 3V3
 
−
| 3V2
 
−
|-
 
−
| Ground
 
−
| GND
 
−
| GND
 
−
| GND
 
−
|-
 
−
| UART Channel 1
 
−
| TX
 
−
| RX
 
−
|
 
−
|-
 
−
| UART Channel 2
 
−
| RX
 
−
| TX
 
−
|
 
−
|-
 
−
| CAN TXD
 
−
|
 
−
| CAN TD1
 
−
| TXD
 
−
|-
 
−
| CAN RXD
 
−
|
 
−
| CAN RD1
 
−
| RXD
 
−
|-
 
−
|}
 
−
 
 
−
The Bluetooth Bee Module interfaces with an Android device through Bluetooth. In addition, various commands and data are then sent and received to and from the CAN bus through the Bluetooth Module to the Android device.
 
−
 
 
−
==== Software Design ====
 
−
*The bridge controller and Android APP work as routers
 
−
 
 
−
''Bridge Controller ''
 
−
*Bridge controller translates CAN bus data into plain text and send it to android platform
 
−
*The Bridge controller is comprised of the SJSU Development Board with the Bluetooth Bee Module.
 
−
*The Bluetooth Bee Module can be configured by writing to UART3 specific commands as specified in the [http://www.seeedstudio.com/wiki/Bluetooth_Bee Bluetooth Bee Seeedstudio Wiki].
 
−
*The Bluetooth Bee Module was configured as SLAVE MODE via the command: ''\r\n+STWMOD=0\r\n'' (The Android device will act as the Bluetooth Master)
 
−
*The Bluetooth device name was set to "Yam_BluetoothBee" using the command: ''\r\n+STNA=Yam_BluetoothBee\r\n''
 
−
*Allowing other devices to connect to the Bluetooth Module was enabled using the command: ''\r\n+STOAUT=1\r\n''
 
−
*Finally the Bluetooth Bee Module started broadcasting/inquiring to connect to another device using the command: ''\r\n+INQ=1\r\n''
 
−
*There are many other commands, such as to change the default pincode value, but they were not used for this project.
 
−
 
 
−
 
 
−
{| style="width:800px;" |
 
−
|[[File:Bridge main system flow Dia.png|700px|thumb|left|Bridge framework ]]
 
−
|}
 
−
''Android Controller ''
 
−
*Android platform receives the text data from bridge controller, then, transmit the data through ajax or websocket
 
−
*External controller could be any TCP accessible device (simple pebble watch program (20 lines) are used to control start and stop)
 
−
*One administrator(control and receive), multiple observers(only receive)
 
−
*Number of way points and routing is dynamically determined and done using the Google Maps API
 
−
 
 
−
 
 
−
{| style="width:800px;" |
 
−
|[[File:Bridge framework.png|400px|thumb|left|Bridge framework ]]
 
−
|[[File:Bridge cross.png|800px|thumb|left|cross platform ]]
 
−
|}
 
−
 
 
−
 
 
−
{| style="width:800px;" |
 
−
|[[File:T3OP Android Intro.png|200px|thumb|left|Intro]]
 
−
|[[File:T3OP_Android_Menu.png|200px|thumb|left|Intro]]
 
−
|[[File:T3OP_Android_OverView.png|200px|thumb|left|Intro]]
 
−
|[[File:T3OP_Android_Map.png|200px|thumb|left|Intro]]
 
−
|}
 
−
<BR/>
 
−
 
 
−
=== Sensors : Sonar Sensors + IR Sensors ===
 
−
 
 
−
====A) Sonar Sensor:====
 
−
*The ultrasonic sensors are in air, non-contact object detection and ranging sensors that detect objects within an area.
 
−
*We are using 3 such sensors in front to get wide angle vision for the car.
 
−
*Ultrasonic sensors use high frequency sound to detect and localize objects in a variety of environments. Ultrasonic sensors measure the time of flight for sound
 
−
that has been transmitted to and reflected back from nearby objects. Based upon the time of flight, the sensor then outputs a range reading.
 
−
 
 
−
====B) Infrared Sensor (IR):====
 
−
*The basic principle of operation of an infrared sensor is based on infrared light that is reflected when its hits an an obstacle. An IR receiver captures
 
−
the reflected light and the voltage are measured based on the amount of light received.
 
−
*IR Sensors have 3 pins to connect to SJOne Board:
 
−
<br>1) Ground (GND)
 
−
<br>2) +Vcc (5 V)
 
−
<br>3) Vo (ADC-4 is on P1.30, select this as ADC0.4)
 
−
 
 
−
{| style="width:800px;" |
 
−
|[[File:BlockDiag.JPG|700px|thumb|left|IR Sensor Block Diagram ]]
 
−
|}
 
−
 
 
−
{| style="width:800px;" |
 
−
|[[File:IR Sensor Graph.JPG|700px|thumb|right|Calibrated voltage output with distance ]]
 
−
|}
 
−
 
 
−
===I/O Unit:===
 
−
*The IO Control Unit manages the LCD Display, switch to start and stop the car
 
−
*It receives CAN data from the Master controller and accordingly processes to display on the LCD through UART
 
−
* The 7 segment LED displays the CPU usage
 
−
 
 
−
''LCD Display ''
 
−
*The LCD Display is placed on the rear side of our RC Car
 
−
*It displays the sensor and GPS values in real time.
 
−
 
 
−
{| style="width:800px;" |
 
−
|[[File:LCD.jpg|400px|thumb|left|LCD Software Interface ]]
 
 
|}
 
|}
−
<BR/>
+
->'''Junk values being printed:'''
 +
*Although this error was not a show stopper, LCD printed junk values whenever it was on and any of the boards were programmed.
 +
**So, the only solution was to never program the board (connect the board to laptop) when LCD is on.
  
 +
->'''Coding improvement'''
 +
*In the code, initially, the GPS, Sensor values were being printed in one line in the code. So, either the values were overwritten or there was shifting of those values. This was a synchronization issue.
 +
**Resolved it by, clearing each line in the LCD before printing it and used individual line in the code to print the values.
  
−
==== Hardware Interface ====
+
== Conclusion ==
−
 
+
The whole project experience was fun and very educational. We learned about how CAN bus, sonar sensor, accelerometer sensor, light sensor, gps and compass module and motor controllers works. We faced some technical challenges such as controlling the motor speed, getting the right distance value from the sonar sensor, getting accurate readings from gps and compass and some of the power issues such as the right amount of current to the DC motors.  
−
=== Motor Controller ===
 
−
==== Hardware Design ====
 
−
[[File:Capture12.PNG|Anatomy of The Rustler]]
 
−
===== Parts and their functions =====
 
−
[[File:Capture7.PNG|thumb|right|Velineon 3500 Brushless Motor]]
 
−
'''''Motor''''' : Our RC car came with Velineon 3500 Brushless Motor. One of the main drawbacks of brushless motor is that it requires a speed controller to change the field polarity. We can't just give power to the motor directly and expect it to go. We can almost consider the controller as an integral part of the motor itself.
 
−
 
 
−
[[File:Capture5.PNG|thumb|left|Velineon VXL-3s ESC]]
 
−
'''''ESC''''' : Electronic speed controller was the trickiest part to deal with, since it comes with a previously programmed microcontroller inside it. It needs callibration, for which you need to refer to the user manual. An electronic speed controller basically controls the power given to the motor. Our RC car came with VXL-3s ESC, which accepted 100 Hz PWM input signal whose duty cycle varied from 10% to 20%. When supplied with a 15% duty cycle at 100 Hz, the ESC responded by turning off the motor attached to its output.
 
−
 
 
−
'''''Steering Servo''''' : Our RC car was equipped with a digital servo (Traxxas part #2075) for steering control. It does not require an ESC to operate. We can give PWM signal directly to the servo from the SJOne board. The servo accepted 100 Hz PWM input signal whose duty cycle varied from 10% to 20%, where 10% represents extreme right turn and 20% represents extreme left turn.[[File:Capture8.jpg|thumb|right|Steering Servo]]
 
−
 
 
−
'''''Speed Sensor''''' : To measure the RPM and speed of our car, we used the speed sensor provided by Traxxas Telemetry. This magnetic speed sensor worked on Hall effect. To learn more about Hall effect sensors, you can click on this [http://en.wikipedia.org/wiki/Hall_effect_sensor wikipedia article]. Since the sensor was provided by the same brand of our car, the installation was quick and easy. Here's a reference [https://www.youtube.com/watch?v=xx-Ft_kzTzs video] on how to attach magnetic speed sensor to the RC car.
 
−
 
 
−
[[File:Capture11.jpg|thumb|left|Traxxas 7-Cell 8.4V NiMH Battery Pack]]
 
−
'''''Battery''''' : We used 7 Cell NiMH (Nickel-Metal Hydride) battery pack for our car but would recommend others to use Lipo (Lithium Polymer) batteries instead. NiMH batteries tend to discharge very quickly. Also we realized later that since this car was made for racing purpose, its speed was too fast for our project. We reduced the voltage by removing 2 cells from the 7 cell battery pack. So, go for the 5 cell battery pack instead. A Traxxas EZ-Peak Charger would help a lot while doing testing.
 
−
 
 
−
==== Hardware Interface ====
 
−
===== Motor and Servo Interface =====
 
−
[[File:Capture13.PNG]]
 
−
 
 
−
===== Speed Sensor Interface =====
 
−
 
 
−
==== Software Design ====
 
−
===== Master Controller =====
 
−
The software implementation of the master controller is explained by the flowchart.
 
−
 
 
−
[[file: CMPE243_Team3_MASTER.jpeg]]
 
−
 
 
−
== Testing & Technical Challenges ==
 
−
===Sensor Controller===
 
−
*Front and Back Sensors Controller
 
−
**Describe how you tested the Sensors and calibration of the sensors
 
−
 
 
−
Mention the Issues you faced and also the solutions you'll used to overcome the problem.
 
  
−
===Motor Controller===
+
This project can be expanded to include more features such as an sonar sensor connected to the servo motor that rotates 360 degree to get distance from all the sides. This can reduce the number of sonar sensors. Furthermore, a improvement can be done in master and motor controller to control the car more precisely by controlling the car movement more accurately. A future suggestion would be to avoid non avoidable obstacles such as grass or follow only the planned route (may be be using some sensors or image detection).
−
*Motor Controller
 
−
**Describe how you tested the motors. Explain the speed control methods used and difficulties you faced during calibration.
 
−
Mention the Issues you faced and also the solutions you'll used to overcome the problem.
 
−
 
 
−
===I/O Controller===
 
−
 
 
−
{| style="width:800px;" |
 
−
|[[File:LCD error.jpg|700px|thumb|left|LCD junk values]]
 
−
|}
 
−
->'''Junk values being printed:'''
 
−
*Although this error was not a show stopper, LCD printed junk values whenever it was on and any of the boards were programmed.
 
−
**So, the only solution was to never program the board (connect the board to laptop) when LCD is on.
 
  
−
->'''Coding improvement'''
+
=== Project Demonstration Video ===
−
*In the code, initially, the GPS, Sensor values were being printed in one line in the code. So, either the values were overwritten or there was shifting of those values. This was a synchronization issue.
 
−
**Resolved it by, clearing each line in the LCD before printing it and used individual line in the code to print the values.
 
−
 
 
−
===Communication Bridge===
 
−
''TESTs''
 
−
*100000 message(20bytes per message) Bluetooth transmission between board and android under 200fps with range <5m
 
−
**100% success
 
−
 
 
−
''ISSUE''
 
−
*3G network server could not be access(3G network is used for long range communication)
 
−
**might use google sheet or external server to communicate
 
−
 
 
−
===Geographical Controller===
 
−
*Geographical Controller
 
−
**Describe how you tested the Compass and explain how did you manage to achieve the maximum accuracy.
 
−
Mention the Issues you faced and also the solutions you'll used to overcome the problem.
 
−
 
 
−
===Master Controller===
 
−
*Master Controller functions as the brain of car. The only challenge was integrating the master controller with the remaining five controllers.
 
−
**Describe how you tested the Master Controller and problems faced while integrating it with all the other controllers.
 
−
Mention the Issues you faced and also the solutions you'll used to overcome the problem.
 
−
 
 
−
== Conclusion ==
 
  
−
=== Project Video ===
+
*  [https://www.youtube.com/watch?v=GBdmSaDHRtw CmpE243_F14_T3_ProjDemo]
  
 
=== Project Source Code ===
 
=== Project Source Code ===
Line 1,929: Line 1,942:
 
== References ==
 
== References ==
 
=== Acknowledgement ===
 
=== Acknowledgement ===
 +
We would like to thank our instructor Preet for always inspiring and encouraging us to learn and build cool projects related to embedded systems. We really appreciate his patience and his guidance. This was our first exposure to CAN bus communication and we learned a lot about it. Last but not the least we would like to thank our awesome team members for supporting each other and helping each other out while working on this project.
  
 
=== References Used ===
 
=== References Used ===
Line 1,948: Line 1,962:
 
http://www.seeedstudio.com/wiki/Bluetooth_Bee
 
http://www.seeedstudio.com/wiki/Bluetooth_Bee
  
−
=== Appendix ===
+
http://www.adafruit.com/product/746

Latest revision as of 08:55, 14 April 2015

Contents

Optimus Prime: The Self-driving Car

Optimus Prime

Optimus Prime, the self-driving car is an autonomous driving vehicle which is capable of driving itself to its destination using GPS. While it does so, it also avoids obstacles using multiple sensors attached to it. It has an LCD screen to display the useful information about the car in real time e.g. distance to the destination, speed, vehicle battery status, etc. The car can be controlled using an android app. This app was designed and developed specifically for this project. Using this app one can start and stop the car, increase or decrease the speed and set a destination to drive up to. This report is about designing and building this self governing car. This documentation is done keeping in mind the students who want to build their own self-driving car and for the curious ones who just want to know what goes inside an autonomous driving vehicle.

Abstract

A self-driving car comprises of several controllers, each with a specific task dedicated to it. Our car consists of 6 such controllers. We have named them as Master, Motor, Sensor, GPS, Communication Bridge and I/O controllers. They communicate with each other over the CAN bus as shown in the diagram below. Each controller sends out the information over the CAN bus in the form of messages. Every controller receives only the required messages and performs the necessary task. The path navigation is achieved by the GPS. Thus the controllers do the task of a driver and navigate the path by avoiding the obstacles.The overall block diagram of the project is shown below. It includes all six controllers with their sensors and actuators, communicating through a CAN bus.

Project Block Diagram

Parts List & Cost

Item# Part Desciption Vendor Part Number Qty Cost
1 RC Car Amazon.com Traxxas 37076 Rustler VXL 1 $380.57
2 RC Car Battery Amazon.com Traxxas 2926 NiMH 8.4V Hump 3000mAh TRA Connector 2 $67.38
3 CAN Transceiver Texas Instrument SN65HVD232D 15 $75.00
4 Assembly Components Amazon.com, Anchor & HSC PCBs, Mechnical & Electical Components NA $110.80
5 Power Supply Pololu.com 6V Battery, 5V Regulator 1 $34.85
6 Sonar sensor Maxbotix LV-MaxSonar-EZ1 MB1010 3 $99.55
7 Sonar sensor Given by Preet LV-MaxSonar-EZ1 MB1010 1 Free
8 Compass Module Given by Preet HoneyWell: HMC 6352 1 Free
9 LCD Display New Haven NHD-0216B3Z-FL-GBW-V3-ND 1 $27.00
10 Battery Status Amazon.com Dc 4.0-30v LED Digital Display Voltage Meter 1 $6.91
11 Bluetooth Bee Amazon.com B005GI4HFA 1 $23.00
12 Sensor RPM Long Sheldon's Hobbies Traxxas #6520 1 $11.99
13 Wire retainers/Gear Cover Sheldon's Hobbies Traxxas #6537 1 $2.99
14 Telemetry Trigger Magnet & Hold Sheldon's Hobbies Traxxas #6538 1 $2.99
15 Front Bumper & Screws Sheldon's Hobbies TRA2542 1 $9.94
Total Cost 849.13

Team Schedule

Sl.No Start Date End Date Task Status Actual Completion Date
1 09/15/2014 09/16/2014 Order RC Car Completed on time 09/20/2014
2 09/15/2014 09/16/2014 Order Other parts(Sensor/LCD/Motor Controller...) Completed 09/20/2014
3 9/30/2014 11/25/2014 Master Controller Team task Completed 12/18/2014
4 10/06/2014 11/15/2014 Sensor Team task Completed 11/15/2014
5 9/30/2014 10/20/2014 Motor Controller Team task Completed 11/25/2014
6 10/4/2014 10/30/2014 Geographical Controller Team task Completed 12/18/2014
7 10/7/2014 10/30/2014 I/O Team task Completed 11/25/2014
8 9/30/2014 11/30/2014 Communication Bridge + Android Team task Completed 11/30/2014
9 10/30/2014 11/01/2014 Complete project integration Completed 11/30/2014
10 11/30/2014 12/10/2014 Testing Phase-1 Completed 12/10/2014
11 12/11/2014 12/14/2014 Testing Phase-2 Completed 12/14/2014

Introduction

CAN Bus: A brief introduction

Controller Area Network is a serial communication bus which allows microcontrollers to communicate with each other within a vehicle without a host computer. It uses differential transmission on a twisted pair wire which results in high immunity to electrical interference. Each microcontroller works as a node. There are several nodes that are connected to each other through a CAN bus. Each node is able to send and receive messages, but not simultaneously. There is an arbitration scheme which works on message priority. Each microcontroller has its own message ID. Lower message ID represents higher message priority. To learn more about CAN bus communication, visit the following wikipage article.

The Six Controllers

Design & Implementation

Controller Communication Table

Controllers
Controller ID Controller Type
0x01 Master Controller
0x02 Motor Controller
0x03 Sensor Controller
0x04 Geographical Controller
0x05 IO Controller
0x06 Bridge Controller
Common Communication Table
Message Number Purpose / Data layout
0x101 Get version and boot info
0x102 Get general info
0x103 Synchronize (set) time: 
byte [0-3] : System time
0x201 
byte [0-3] : Version Info
byte [4-7] : boot timestamp
0x202 
byte [0-3] : Current time
byte [4]   : CPU usage %
Subscription Rate Info
Byte 0 Effect
0 Off
1 1Hz
5 5Hz
10 10Hz
20 20Hz
50 50Hz
Any other value Invalid date rate

Master Controller

Group Members

Bhargava Leepeng Chandra
Preeti Benake

Description

Master controller acts as the 'Brain' of the car. It communicates with all the other Controllers on board to implement different Functions. Being the Brain it intelligently processes the data it receives from Sensor, GPS and Bridge controllers to make the car run autonomously. It has several features embedded in it, and controls the car by sending commands to the Motor Controller. In short the master controller actively Receives, Processes and Transmits real-time data.

Master Controller Team Schedule

Week No. Start Date Planned End Date Task Status Actual End Date
1 9/30/2014 10/7/2014 
* Implement Basic CAN Hardware to communicate between 2 Controllers
  • Completed
We are able to send a message from Tx over CAN and perform a specific operation at the Rx.
 10/7/2014
2 10/7/2014 10/14/2014 
* Design CAN Acceptance Filter among different Controllers
* Define and Implement CAN Frame structure for proper communication
  establishment
  • Completed
Only messages with in range of acceptance filter are received, Decided on CAN frame structure using 11-bit frame.
 10/11/2014
3 10/14/2014 10/21/2014 
* Develop Inter-Controller Communication over CAN
* Test point-to-point and Broadcast message transmission
* Implement a Counter to count and display number of messages
  • Completed
CAN Communication among multiple boards achieved, Point-to-Point & Broadcast modes are working, Able to display the count on 7-Seg Display on SJOne board.
 10/19/2014
4 10/21/2014 10/28/2014 
* Layout blueprint for Controller and Module positioning 
* Assemble the RC Car with all the controllers and Modules
* Define the Message List by working with other teams
* Start working on CAN Periodic message structure
  • Completed
RC car design and module assembly is completed. Need some fine tuning for connections. Message list is generated and periodic message implementation started.
 10/28/2014
5 10/28/2014 11/04/2014 
* Complete CAN Periodic message structure to transmit Broadcast
  messages over CAN and establish controlled communication among
  different controllers 
* Implement Start condition detection and Fetch boot status from
  all controllers and display the status of each controller
  • Completed
Periodic Message Setup done. Able to receive boot status. Need to work on display of status.
 11/03/2014
6 11/04/2014 11/11/2014 
* Design 'Kill Switch' in co-ordination with Motor Controller team
  and Bridge Controller team
* Develop a 'CAN Bus Crash' detection and reset CAN Bus methodology
* Design Automatic Head Light turn ON/OFF functionality by
  working with Sensors Controller team
  • Completed
Kill Switch implemented through Bridge controller. Head Lights implemented. LCD display of Status achieved.
 11/11/2014
7 11/11/2014 11/18/2014 
* Implement File Log saving to SD Card at periodic intervals
* Work on Restoring to last known Status if the system crashes while running
* Develop Detection technique if controllers are reaching 'Error State'
  • Completed
File Log implemented. Error State is partially implemented. Obstacle detection achieved. Needed refinement in Direction control logic. Need to implement reverse logic.
 11/18/2014
8 11/18/2014 11/25/2014 
* Project Integration and testing Basic Self_Drive Capability of the Car
* Check the Functionality and behavior of all controllers in all the known 
  contexts
* Perform modifications (if any) to eliminate any bugs to make the car work
  seamlessly
* Final Integration of car and testing there after
  • Completed
Integration Started. Faced difficulty in synchronization.
11/26/2014
9 11/25/2014 12/02/2014 
* Final Integration and testing Self_Drive Capability of the Car
  • completed
We are able to integrate all the different on-board systems and control the features with the master's control algorithm using real-time data from Sensor, Geo and Bridge controllers. The primary objective of self-drive capability is achieved. We have faced little difficulty in adjusting the frequency of data appropriate to real time needs.
 12/8/2014
10 12/02/2014 12/18/2014 
* Final Testing with all Features
  • completed
Checked out the Data Log for any possible message drops. Resolved issues related to Compass.
 12/15/2014

Hardware Design

  • An RC car was used as a base to demonstrate the Self-Driven Capability of a car with all the Controlling done by SJOne boards.
  • The hardware for this Project is custom designed according to the requirements of the project.
  • This includes building the Chassis to place all the SJOne boards.
  • Sufficient Power and Ground slots for all the Sensors, GPS, Compass, LCD breakout boards.
  • Designing a CAN bus structure for establishing communication among different SJOne boards.
  • Designing a Spike protection for the Input power supply.
  • Finally Sufficient number of pins(if necessary) to connect external Breakout boards to the SJOne controllers.

Hardware Implementation

  • First we have started by designing the chassis using a PCB as base to place all the SJOne boards that represents the 6 sub-teams,this includes a separate base for placing LCD module, Head-lights and Tail-lamps.
  • As a second step we moved forward by designing the circuitry for Power Supply and Spike protection by designing a 5V voltage regulator, that serves as a power supply to all the SJOne controllers and LCD module.
  • Then sufficient VCC and GND slots were added to the PCB that could accommodate Sonar sensors, GPS and Compass modules, Head-lights and Tail-lamps.
  • Later a common CAN bus structure was designed to support the CAN transceivers for each individual SJOne board. The entire system is built around this CAN structure.
  • Then the Hardware was made robust enough to take all the hits during the testing process.


Following is the top view of the car showing the connection of all the 6 controllers and the hardware interfaced to each of them.

Cmpe243 team3 Block.JPG

Hardware Challenges and Difficulties

  • The major challenge is to design a common CAN bus structure. One need to understand the electrical characterisitcs of CAN in order to design it better. We had to go through several debugging stages to evaluate the perfromance of the CAN bus as it used to fail at times.
  • Care must be taken in designing the connections for CAN-HIGH and CAN_LOW. The supply for each CAN needed to be separate in our case in order to provide sufficient drive current to the CAN transceiver.
  • Next to this another challenge was to make the Hardware robust. During the testing phase it takes a lot of hits and bangs, the module fitting and the circuitary needs to be good enough to absorb all the pressure. By reducing the number of wired connections the robability of hardware fails can be reduced.
  • Another difficulty was to supply PWM signals to the Motor. The Signals should be strong enough to run the DC motor and Servo motor of the car. It happened to be that if the trace/wire connection is too long the PWM signal is losing its strength. So it should be as much near to the motor as possible.
  • The positioning of the Sonar sensors should be appropriate to avoid any bounce off, To deal with the bouncing effect we should place it at some height/angular height to reduce the possiblity of bouncing from the ground. Also each sensor should be at a distance and angle with respect to other sensors to facilitate sufficient area of detection.
  • The positioning of Compass module is a little bit tricky. This should be far away from Electrical/Magnetic interferences as it very sensitive to these effects. So we placed it on the top at a height to avoid any corrupted values.

Hardware Interface

Block diagram of Master controller
Master Controller Pin Connectivity Table
Description Your Device Port SJOne Development Board Port
Supply Voltage Supply +5V Board +5V
Ground Supply GND Board GND
CAN Transceiver Pin no. 1 Driver Input

Pin no. 4 Receiver Output

P0.1 CAN TD1

P0.0 CAN RD1

Head Lights LED +3.3V

LED GND

Pin 1.20, 1.22 GPIO

Common GND

LED Strip LED Strip DIN

LED Strip +5V

LED Strip GND

Pin 1.29 GPIO

Common VCC

Common GND

Software Design

  • Master controller which is the central controller, performs all its functions with FreeRTOS software running at its core.
  • The two key components of FreeRTOS utilized by Master to achieve these operations are
1. FreeRTOS Task and Scheduler
2. FreeRTOS Queues
  • Master controller heavily rely on the FreeRTOS scheduler, for most of the time to run various tasks, which are responsible for what the master controller does.
  • The FreeRTOS queue structure is used to achieve inter-task communication inside the Master controller to process data and transmit to respective controllers.
  • CAN bus structure with 29 bit message ids is used to establish communication among different controllers. The Broadcast bus made point to point to exchange data between any two controllers by configuring an additional Acceptance filter.
  • The periodic CAN message structure provided by Preet helps transmit specific data to specified destination at a specified interval like 1Hz, 5Hz, 10Hz etc.
  • The File logger task runs along with other tasks to log real time data onto SD card in order to facilitate debugging without sacrificing the speed for debugging.
  • Additional features like Light sensor controlled Head Lights are implemented to make the car feasible for low light/night time runs.
  • Apart form this an LED strip is used to indicate when the car is being run on sensor's data, when an obstacle is detected. This distinctively demonstrates when the car is controlled by a particular controller among the Geographical controller and Sensor controller.

Software Implementation

  • The implementation of the specified software design for master controller is achieved by using the FreeRTOS and CAN libraries provided by Preet.
  • The Master operation starts with the initilization of CAN Bus and configuring the CAN acceptance filter. The sample code is shown below.


CmpE243 F14 T3 CAN INIT.PNG


  • In main the control next creates new tasks like Receive task to deal with different functions, which will only start running after the scheduler.
  • These tasks supply Data to periodic tasks next in the line to Transmit data over the CAN bus to the specified destination.


CmpE243 F14 T3 Tasks.PNG


CmpE243 F14 T3 Periodic.PNG


  • The FreeRTOS queues exchange data among different tasks to process the data. This comprises data from Sensors, Geo and Bridge Controllers.
  • The Processed data put into the Decision making algorithm performs direction and speed controlling operations.


The software design and implementation of the master controller is explained by the flowchart.

CMPE243 Master 1.jpg

Implementation

Master Controller Communication Table
Message Number Purpose Data Byte Pattern
0x101 Ask for Boot and Version Info. of all Controllers 
Byte[0]: Send a '1'
0x103 Sync. Master System Time on all Controllers 
Byte[0-3]: System Time [HH:MM:SS]
0x201 Master Gets Status Update from all controllers 
Byte[0]: Boot Status
Byte[1]: Version Info.
0x203 Master Gets current Time from all Controllers 
Byte[0-3]: Time in [HH:MM:SS]
0x301 Master Enable Main UI in Android 
Byte[0]: Send a '1'
0x302 Master set GPS Destination on Geo Controller 
Byte[0-3]: Latitude Value
Byte[4-7]: Longitude Value
0x303 Master set Longitude Way-Points on Geo 
bytes [0-1] : Total Way-Points count
bytes [2-3] : Way-Point index
bytes [4-7] : Longitude(float)
0x304 Master set Latitude Way-Points on Geo 
bytes [0-1] : Total Way-Points count
bytes [2-3] : Way-Point index
bytes [4-7] : Latitude(float)
0x305 Master Send GPS FIX Ack to Bridge 
Byte[0]: Send a value '1'
0x306 Master Send Dest. Reached Ack to Bridge 
Byte[0]: Send a Value '1'
0x500 Display Boot and Version Info. on LCD 
Byte[0]: Boot Status Response
Byte[1]: Version Info.
0x501 Display Controllers Time on LCD 
Byte[0-3]: Time in [HH:MM:SS]
0x502 Display Destination Has Reached 
Byte[0]: Send a '1'
0x503 Master Set Speed and Direction of Motor 
Byte[0]: LEFT/RIGHT (or) FRONT/BACK command
0x504 Display Speed of Motor on LCD 
Byte[0]: Speed Value
0x505 Display GPS and Compass values on LCD 
Byte[0-1]: New Degree to Head
Byte[2-3]: Dist to Destination
Byte[4-5]: Current Degree value
0x506 Display Sensor Values on LCD 
Byte [0]: Front sensor value in inches
Byte [1]: Front Left sensor value in inches
Byte [2]: Front Right sensor value in inches
Byte [3]: Back sensor value in inches
0x507 Display Battery Status on LCD 
Byte[0]: Battery Status Value
0x540 Send GPS Data to Bridge 
Byte[0-1]: Heading Degree
Byte[2-3]: Dist. to Destination
Byte[4-5]: Current Bearing Degree
Byte[6-7]: Difference between Heading and Bearing angle
0x550 Send Sensor Data to Bridge 
Byte[0]: Front Sensor
Byte[1]: Front Right Sensor
Byte[2]: Front Left Sensor
Byte[3]: Back Sensor
Byte[4]: Speed value

Testing and Technical Challenge

We have faced several Difficulties during Software design implementation for Master Controller. Some of these issues are discussed here.

  • Top of the list is the Integration. We have faced difficulty in achieving the integration of all the individual controllers working together in synchronization with each other.
  • Another issue is the CAN bus communication failure which is due to improper transmitting formats like message ID duplication causing the CAN bus error. There are also issues due to improper configuration of acceptance filter, which is later resolved.
  • We have also faced difficulty when using the FreeRTOS queues, This is caused due to using a particular queue at some locations before it is actually declared declared.
  • Apart from this the Queue timing implementation has to be observed carefully as it may conflict the frequency of real time Data that causes error status as the receiving queue task cannot see any data on the queue.
  • We have faced difficulty in data synchronization during testing. The real-time data needs forced us to modify the Transmitting frequencies from certain controllers, particularly for Geographical controller.

Motor Controller

Group Members

Shashank Tupkar
Naghma Anwar
Shiva Moballegh

Motor Controller Team Schedule

Week No. Start Date Planned End Date Task Status Actual End Date
1 9/30/2014 10/7/2014
  • Study SJOne board's motor controller concepts and PWM
  • Completed
Very simple code. Just two lines. Set the frequency. Set the duty cycle.
 10/7/2014
2 10/7/2014 10/14/2014
  • Open up RC Car's motor and servo connections
  • Study the Electronic Speed Control's functions
  • Completed
Motor and Servo operate on the same frequency
ESC needs calibration each time it is switched on. Need to find a solution for this.
 10/11/2014
3 10/14/2014 10/21/2014
  • Define the duty cycles for proper motor and servo signals
  • Completed
Using trial and error, figured out the duty cycle for constant speed and turns
 10/19/2014
4 10/21/2014 10/28/2014
  • Add CAN frame structure to the motor functions
  • Test for communication between motors and sensors for prototype demo
  • Define the Message List by working with other teams
  • Completed
 11/04/2014
5 10/28/2014 11/04/2014
  • Start working on CAN Periodic message structure
  • Start looking for speed sensors
  • Completed
Bought magnetic speed sensor from Traxxas telemetry
from local RC Car store
 11/04/2014
6 11/04/2014 11/11/2014
  • Attach speed sensors to the motor
  • Test CAN communication between motor controller and other controllers
  • Completed
Speed sensors attached
 11/11/2014
7 11/11/2014 11/18/2014
  • Work on speed sensors. Figure out the way to send sensor data to master controller.
  • Test for proper and accurate CAN communication
  • Completed
 11/18/2014
8 11/18/2014 11/25/2014
  • Project Integration and testing basic self drive capability of the car
  • Check the functionality and behavior of the motor controller in all the known contexts
  • Perform modifications (if any) to eliminate any bugs to make the motor work seamlessly
  • Final Integration of car and testing there after
  • Completed
 12/12/2014

Hardware Design

Anatomy of The Rustler

Parts and their functions
Velineon 3500 Brushless Motor

Motor : Our RC car came with Velineon 3500 Brushless Motor. One of the main drawbacks of brushless motor is that it requires a speed controller to change the field polarity. We can't just give power to the motor directly and expect it to go. We can almost consider the controller as an integral part of the motor itself.

Velineon VXL-3s ESC

ESC : Electronic speed controller was the trickiest part to deal with, since it comes with a previously programmed microcontroller inside it. It needs callibration, for which you need to refer to the user manual. An electronic speed controller basically controls the power given to the motor. Our RC car came with VXL-3s ESC, which accepted 100 Hz PWM input signal whose duty cycle varied from 10% to 20%. When supplied with a 15% duty cycle at 100 Hz, the ESC responded by turning off the motor attached to its output.

Steering Servo : Our RC car was equipped with a digital servo (Traxxas part #2075) for steering control. It does not require an ESC to operate. We can give PWM signal directly to the servo from the SJOne board. The servo accepted 100 Hz PWM input signal whose duty cycle varied from 10% to 20%, where 10% represents extreme right turn and 20% represents extreme left turn.
Steering Servo

Speed Sensor : To measure the RPM and speed of our car, we used the speed sensor provided by Traxxas Telemetry. This magnetic speed sensor worked on Hall effect. To learn more about Hall effect sensors, you can click on this wikipedia article. Since the sensor was provided by the same brand of our car, the installation was quick and easy. Here's a reference video on how to attach magnetic speed sensor to the RC car.

Traxxas 7-Cell 8.4V NiMH Battery Pack

Battery : We used 7 Cell NiMH (Nickel-Metal Hydride) battery pack for our car but would recommend others to use Lipo (Lithium Polymer) batteries instead. NiMH batteries tend to discharge very quickly. Also we realized later that since this car was made for racing purpose, its speed was too fast for our project. We reduced the voltage by removing 2 cells from the 7 cell battery pack. So, go for the 5 cell battery pack instead. A Traxxas EZ-Peak Charger would help a lot while doing testing.

Gears : Gears also play an important role in determining the Speed of the car. A gear is defined by the number of Cogs (teeth) which determines if the gear increases (or) decreases the output speed delivered to the axle. So, we can also opt for different gears to reduce the overall speed in any case necessary. In our case changing the gears isn't an option since our car is set with the minimum gear as it belongs to sports car category. But however some custom gears can still do the job in reducing the unnecessary speed, though they are a little bit hard to get our hands on it.

Hardware Interface

Motor, Servo and Speed Sensor Interface

CmpE243 F14 T3 PinConnection.png

Motor Controller Pin Connectivity Table
Description Your Device Port SJOne Development Board Port Commands Note
Supply Voltage 6V from NiMH battery N/A
Ground GND (Black Wire) GND
ESC 
 Control (White Wire)

 P2.0 PWM

 PWM motor(PWM::pwm1, 101);
 motor.set(14.5);

 Sets PWM signal of 101 Hz
 Sets duty cycle of 14.5% for forward movement
Servo 
 Control (White Wire)

 P2.1 PWM

 PWM servo(PWM::pwm2, 101);
 servo.set(15);

 Sets PWM signal of 101 Hz
 Sets duty cycle of 15% for no turn
Speed Sensor 
 Signal (White Wire)

 P2.2 PWM

 It contains a trigger magnet and an rpm sensor
 It works on Hall effect.
CAN Transceiver 
 Pin no. 1 Driver Input
 Pin no. 4 Receiver Output

 P0.1 CAN TD1
 P0.0 CAN RD1

 TI CAN Transceiver SN65HVD232D
 Pin 7 - CAN H & Pin 6 - CAN L

Software Flow

CmpE243 F14 T3 MotorFC.jpg

Implementation

Motor Controller Communication Table
Message Number Purpose Data layout
0x508 Speed Sensor Data 
byte [0] : Speed sensor value in rpm
0x503 Vehicle Direction/Movement Data 
byte [0] : Movement Control
     0x1 : Forward Fast
     0x2 : Forward Slow
     0x3 : Right
     0x4 : Left
     0x5 : Stop
     0x6 : Back Right
     0x7 : Back Left
     0x8 : Back

Testing and Technical Challenge

  • Motor Controller
    • ESC
      • Electronic Speed Control is tricky to handle since it has its own pre-programmed micro-controller inside it which needs calibration according to the user manual.
      • We started with calibrating the ESC using RC car's transmitter, but later we had to write our own calibration code.
    • Motor
      • We tested the motor speed by measuring the PWM signal on oscilloscope. We started by reading the PWM signal on oscilloscope while manipulating the speed of the RC car using its transmitter module.
      • Since the car was made for racing purpose, we had to keep the speed to its lowest value.
      • The transmitter and receiver of the RC car was detached from it. We gave PWM signal to the ESC and Servo through SJOne board.
      • It turned out that ESC was not accepting the PWM signal because it needed calibration each time its setting is changed.
      • We overcame this problem by including a calibration init code in our program.
      • We also noticed that as we added more hardware on top of the car, its speed was affected because of the load. We had to change the PWM value accordingly.
    • Servo
      • Since servo was not connected to the ESC it was pretty easy to handle. We could give PWM signal directly to servo and it moved accordingly.

Sensor Controller

Group Members

Deepak Yadav
Vinod Pangul

Sensor Team Schedule

Sl.No Start Date End Date Task Status Actual Completion Date
1 10/6/2014 10/18/2014 Order Ultra Sonic Sensors Completed [Got two sensors (front and back), 2 more (front right & left) to order ->Completed.] 10/19/2014
2 10/9/2014 10/9/2014 Sensor Data Sheet review with the team Completed 10/9/2014
3 10/9/2014 10/16/2104 Sensor code development Completed (Implementing filter (HW/SW) to get more accurate data ->(Done). Add logic to get the rest of the three sensor(front right/left and back data)->(Done) (Note: Delayed due to the implementation of CAN structure and calibration of IR sensor) 10/21/2014
4 10/22/2014 10/25/2014 Sensor software testing Completed 10/25/2014
5 10/25/2014 10/28/2014 Sensor real time testing Completed 10/28/2014
6 10/13/2014 10/15/2014 Light sensor code Development Completed 10/14/2014
7 10/13/2014 10/15/2014 Accelerometer sensor code Development to detect tilt Completed 10/14/2014
8 10/15/2014 10/15/2014 Light Sensor and Accelerometer Testing Completed 10/15/2014
11 11/03/2014 11/04/2014 Common Communication SW code implementation and testing Completed 11/04/2014
11 11/04/2014 11/09/2014 Complete Hardware testing-1 Completed 11/09/2014
12 11/10/2014 11/15/2014 Complete Hardware testing-2 Completed 11/15/2014

Sensors : Sonar Sensors + Light and Accelerometer sensor

Hardware Design

CmpE243 F14 T3 HardwareInterface.png

A) Sonar Sensor:

CmpE243 F14 T3 sonarSensor.jpg

  • The LVMax long distance sonar sensors are used to detect the objects. We used four such sensors, three in the front and one in the back to get wide angle vision for the car. The Sonar Sensors sends sound waves when triggered and then the sensor signal emits a PWM that needs to be timed to detect the distance. The PWM width depends on the time it takes for the sound waves to bounce back from an object. The following figure explains how the distance is calculated.

CmpE243 F14 T3 Sensor.jpg

B) Light and Accelerometer Sensor:

  • The inbuilt accelerometer and light sensor on SJoneBoard is used to read their values. The inbuilt driver libraries provide by Prof. Preet is used to read both the accelerometer and the light sensor value and broadcast it over CAN bus for the detection of Car's light and front light of the car.

Software Design

Sonar Sensor
  • Configure PW as input
  • Enable PW as Rising and falling edge interrupt
  • Configure RX as output, and give a 20uS Pulse of HIGH then LOW
  • Take a snapshot of a hardware timer (T1) or start a hardware timer When Rising edge interrupt occur on PW.

--> After few microsecond <--

  • PW will go HIGH,take a snapshot of a hardware timer or start a hardware timer When Rising edge interrupt occur

--> After some time <--

  • PW will go LOW and the interrupt on falling edge will now trigger, Take a snapshot of a hardware timer (T2).
  • Calculate the time difference (T2-T1) and convert the time into inches/CM (Formula is provided by the datasheet).

CmpE243 F14 T3 SensorFlowChart.png

Light and Accelerometer
  • The library provided with SJOne Board has drivers for light and Accelerometer sensors. The only thing is to be done is to read the light sensor and accelerometer sensor data and broadcast to Master controller over CAN bus at rate of 1Hz.

CmpE243 F14 T3 LightAccl.png

Sensor Controller Task
  • Below is the overall flowchart of the sensor controller task.

CmpE243 F14 T3 SensorTask.png

Implementation

Sensor Controller Communication Table
Message Number Purpose Data layout
0x510 Front/Back Range Sensor Data 
byte [0] : Front sensor value in inches
byte [1] : Front Left sensor value in inches
byte [2] : Front Right sensor value in inches
byte [3] : Back sensor value in inches
0x511 Accelerometer/Light Sensor 
byte [0] : X axis Value
byte [1] : Y axis Value
byte [2] : Z axis Value 
byte [3] : Light sensor value

Testing and Technical Challenge

  • Front and Back Sensors Controller
    • To test the Sonar sensors, We placed the object in front of the sonar sensor and checked the pulse generated by the sonar sensors on Oscilloscope. The sensors data is verified by printing it on the Output terminal. We also tested the working of sensor with the moving car. We logged the data on the SD card and also displayed it on the seven segment display when the car was moving.

We used Maxbotix LV-MaxSonar sensors. It has Three mode for getting data-Pulse width (PW), Analog (AN) and RS232. We went for Pulse width mode, because RS232 found to be very inaccurate and needed more pin connections (RX,TX,GND and 4 UART), SJOne board has only three available analog pins for use and we needed 4 of them and also they were not fast enough and their minimum distance is only 6 inch. So, we decided to go for Pulse width mode. The PW mode are much accurate and they are fast. Their distance range is from 3 inch to 254 inch. Moreover, PW can be connected to GPIO pins with external interrupt functionality. Since SjOne Board has more available GPIO pins on Port2 with external Interrupt functionality, PW mode option was chosen.

The sonar sensors needs some time of delay to complete the full distance reading if no object is detected within the max range.The delay is ~50ms for each sensor to complete the distance calculation. So, a min 50ms delay is needed between every next triggering of RX pin. The value provided by the sensors are accurate, but not very stable. We tried using mode filters to avoid unstable readings. The only drawback of using filters was that it slowed down the sensors reading. After few experiment we found out that sensors are much more stable and provide a very accurate reading when we put a large delay around 20 ms between toggling the trigger pin (RX) and polling on CPU and not using external interrupt for calculating the distance time. This method is a very bad design as it can consume unnecessary CPU time, and its max range is not accurate and fixed (due to timeout delay), and it may give inaccurate reading if any interrupt occur. Since sensor task had no other major task running and after few experiment we found out that without using external interrupt and just polling the sensor value (bad design approach) was more reliable and accurate!!. The future implementation would be to find the solution to get the more reliable and accurate data using external interrupt function.

Geographical Controller

Group Members

Bhushan Gopala Reddy
Ryan Marlin
Rishikesh Nagare

Geographical Team Schedule

Sl.No Start Date End Date Task Status Actual Completion Date
1

10/4/2014

10/13/2014

Research and Order GPS module

Received GPS module

10/7/2014

2

10/7/2014

10/18/2014

Interface GPS module with LPC1758

Finished

10/17/14

3

10/14/2014

10/18/2014

Receive Compass module from Preet

Received

10/9/2014

4

10/18/2014

11/4/2014

Parse GPS data and setup constructs to send appropriate data

Finished

11/1/2014

5

10/14/2014

10/18/2014

Interface the Compass Module

Finished

10/16/2014

6

10/25/2014

11/4/2014

Calibration of Compass

Finished

11/1/2014

7

11/4/2014

11/11/2014

Integrate GPS and Compass data

Finished

11/4/2014

8

10/25/2014

11/30/2014

Testing and mapping of GPS co-ordinates

Finished

11/20/2014

9

11/18/2014

12/18/2014

Final integration and testing

Finished

12/15/2014

Hardware Design

CmpE243 F14 T3 HWDesign.png

Hardware Interface

Geographical Controller Pin Connectivity Table
Description Your Device Port SJOne Development Board Port
Supply Voltage Vcc 3v3
Ground GND GND
GPS Module 
Channel 1 -> Rx, Channel 2 -> Tx 

Channel 1-> Tx P2.8, Channel 2-> Rx P2.9
Compass 
SCL
SDA

SCL2 -> P0.11
SDA2 -> P0.10
CAN Transceiver 
Pin no. 1 Driver Input
Pin no. 4 Receiver Output

P0.1 CAN TD1
P0.0 CAN RD1

Software Design

Top level view of GPS software flow

The figure above shows a top level view of the geographical team's software flow. The main message task, shown in the middle, is responsible for handling and updating the CAN message pointer. The CAN message pointer is read and handled in a separate periodic task that runs and sends messages across the CAN bus at frequencies of 1, 5, 10 or 20 Hz.

The GPS and compass tasks, shown on the left and right respectively, collect their respective data and send that data to the message task. The message task will grab this data and stuff the CAN message variable to be sent to the Master module.

CmpE243 F14 TeamUndergrad GPS GPS.jpeg CmpE243 F14 TeamUndergrad GPS compass.jpeg
GPS
NMEA (National Marine Electronics Association)

  • NMEA consists of sentences, the first word of which, called a data type, defines the interpretation of the rest of the sentence.
  • Each Data type would have its own unique interpretation and is defined in the NMEA standard.
  • In our project we are using RMC (Recommended Minimum GPS data).Below is an example of RMC data.

$GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A

Where: 

    RMC          Recommended Minimum sentence C
    123519       Fix taken at 12:35:19 UTC
    A            Status A=active or V=Void.
    4807.038,N   Latitude 48 deg 07.038' N
    01131.000,E  Longitude 11 deg 31.000' E
    022.4        Speed over the ground in knots
    084.4        Track angle in degrees True
    230394       Date - 23rd of March 1994
    003.1,W      Magnetic Variation
    *6A          The checksum data, always begins with *


Connection and Software Flow GPS:

SJone board and GPS module is connected using UART. At boot-up GPS tries to get fix for all possible satellites to get proper GPS values.

Compass
The Compass works over the I2C bus interface. Based on the datasheet, the compass will send data when it receives a 'A' command.

Implementation

GPS Controller Communication Table
Message Number Purpose Data layout
0x518 Send GPS Data to Master 
 byte [0] : New Degree
 byte [1] : Distance
 byte [2] : Current Degree
0x519 Send GPS FIX ACK to Master 
 byte[0]: Send a '1'
0x52A Send Destination Reached ACK to master 
 byte[0]: Send a '1'

Testing and Technical Challenge

  • Geographical Controller
    • GPS
      • GPS data was relatively straightforward to receive, however we ran into quite a few issues trying to parse the data.
      • Often times we would read the UART data in the middle of the buffer being changes to the next data point, for example, the reading would look like this:
        • $GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4$GPRMC,123519,A,4807.038
        • Instead of the normal data point: $GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A
      • By checking the Checksum at the end of the string, *6A, we were able to determine the number of characters that were supposed to be in the string and exclude any strings that did not have the correct number of characters.
    • Compass
      • The Compass data was also straight forward to get. The compass HMC6352 has many useful features as provided in the datasheet, We focused on using the basic output data mode with heading mode.
      • The Compass is very sensitive to any kind of magnetic interference. In our project it were the motors and we had to make sure we mount the compass as far as possible from the motors to avoid any interference even though we had the calibration mode set up.
      • Sometimes the SDA and SCL used to get short (not because of hardware problem) maybe due to line impedance or parasitic capacitance since the wires were close to each other. A software reset can solve the problem.

Android & Communication Bridge Controller

Group Members

Chia-Pin Tseng (Ben)
Johnny Yam
Kevin Beadle

Communication Bridge & Android Team Schedule

Sl.No Start Date Planned End Date Task Status Actual End Date
1 9/30/2014 9/30/2014 Obtain Bluetooth Module (already had one) Done 9/30/2014
2 9/30/2014 10/14/2014 Develop Basic Android App with Bluetooth Sensor Communication Done 10/7/2014
3 10/11/2014 10/14/2014 Interface Bluetooth Module with SJSU Dev Board Done 10/11/2014
4 10/12/2014 10/19/2014 Be able to send bi-directional arbitrary messages between Android App and Dev Board via Bluetooth Done 10/14/2014
5 10/14/2014 11/21/2014 Subscribe to all CAN messages and dump all of them via Bluetooth to Android App or web interface Done 11/24/2014
6 10/14/2014 11/21/2014 Ajax & Websocket server remote structure Done 11/01/2014
7 10/14/2014 11/21/2014 Be able to input GPS coordinates through either (or both) Android App and web interface and send through Bluetooth then CAN bus Done 11/24/2014
8 10/21/2014 11/24/2014 Android App and webpage GUI enhancements (Google Maps, Google Drive) Done 11/24/2014
9 10/21/2014 11/30/2014 Data visualization (status, compass, speed, location,....) Done 11/30/2014

Hardware Design

Bluetooth Bee Module
  • In order to facilitate wireless communication between the SJSU One Board and a Android device, a Bluetooth Bee module is used. This module was chosen because it can connect and mount directly onto the SJSU One Board's XBee breakout socket.
  • The Bluetooth Bee is a Serial Profile Port (SPP) Bluetooth interface that connects with the SJSU development board's UART3.

Hardware Interface

The relevant pin connectivity table between the Bluetooth Bee module and the SJSU One Development Board is shown below:

Communication Bridge Pin Connectivity Table
Description Bluetooth Bee Port SJSU Development Board Port CAN Transceiver
3.3V Supply Voltage 3V3 3V3 3V3
Ground GND GND GND
UART Channel 1 TX RX
UART Channel 2 RX TX
CAN TXD CAN TD1 TXD
CAN RXD CAN RD1 RXD

The Bluetooth Bee Module interfaces with an Android device through Bluetooth. In addition, various commands and data are then sent and received to and from the CAN bus through the Bluetooth Module to the Android device.

Software Design

  • The bridge controller and Android APP work as routers

Bridge Controller

  • Bridge controller translates CAN bus data into plain text and send it to android platform
  • The Bridge controller is comprised of the SJSU Development Board with the Bluetooth Bee Module.
  • The Bluetooth Bee Module can be configured by writing to UART3 specific commands as specified in the Bluetooth Bee Seeedstudio Wiki.
  • The Bluetooth Bee Module was configured as SLAVE MODE via the command: \r\n+STWMOD=0\r\n (The Android device will act as the Bluetooth Master)
  • The Bluetooth device name was set to "Yam_BluetoothBee" using the command: \r\n+STNA=Yam_BluetoothBee\r\n
  • Allowing other devices to connect to the Bluetooth Module was enabled using the command: \r\n+STOAUT=1\r\n
  • Finally the Bluetooth Bee Module started broadcasting/inquiring to connect to another device using the command: \r\n+INQ=1\r\n
  • There are many other commands, such as to change the default pincode value, but they were not used for this project.


Bridge framework

The architecture for our bridge controller is to interconvert the data between Bluetooth message and CAN bus message. Bluetooth message uses simple plaintext to transfer data. However, before we can deal with the string data, to collect and assemble several bytes into a package is needed, because UART is byte based data transmission. I use a byte 0x13(which is ‘\r’ in C code) at the end byte.The bluetooth sender must send 0x13 in the end of every text message. This process is achieved by BluBeeTask_BT2CAN class. CAN bus message uses 29bits as message ID and 8bytes data length as a single package to communicate with the master controller. There are two main classes for the controller. BluBeeTask_BT2CAN and BluBeeTask_CAN2BT.

  • BluBeeTask_BT2CAN

BluBeeTask_BT2CAN is responsible for receiving the data which comes from bluetooth(via UART).We can setup multiple message filters to receive and process certain message data.

Filter setting format. 

    blutoothReceiverTask->addCMD(
    BluBeeTask_BT2CAN::CMDProp::gen((char* cmd,
               bool (*func)(BluBeeTask_BT2CAN *, char* CMDStr)));

For example, there is a message format “Speed” to control the speed of the automatic car. We can simply apply a filter as below 

    blutoothReceiverTask->addCMD(
    BluBeeTask_BT2CAN::CMDProp::gen("Speed", SpeedCMD));


then, we have a callback function “SpeedCMD” that can only receive speed setting messages.(For instance there is a message “Speed23” was sent by Android) 

    bool SpeedCMD(BluBeeTask_BT2CAN *sender, char* CMDStr)//CMDStr will be “23”
    {
        int speed = 0;
        CMDStr=parseInt(CMDStr,&speed);//parse string “23” into integer 23
        can_msg_t msg = { 0 };//CAN message
        msg.msg_id = make_id(cid_master_controller, CAN_TX_CAR_SPEED_MSG_ID);
        //Set the ID to send to master controller with speed message ID 
        *(int *) &(msg.data.bytes[0]) = speed;//First byte is the speed 23
        return sender->Send2CAN(msg);//Send message via CAN bus
    }

You can see the call back function SpeedCMD is doing a very simple string processing, then, send it to the master controller via CAN bus.

  • BluBeeTask_CAN2BT

What BluBeeTask_CAN2BT doing is actually very similar to BluBeeTask_BT2CAN. First, you need to apply CAN message filters and set the corresponding callback functions.

Filter setting format. 

    CANReceiverTask->addMsgTamp(
           BluBeeTask_CAN2BT::MsgProp::gen(
                 (controller_id_t MsgIdTmp, controller_id_t Mask,
           bool (*func)(BluBeeTask_CAN2BT *, can_msg_t Msg)));

controller_id_t is the set of information of CAN message ID including source, destination, and message number. To setup a controller_id_t variable you can simply use a function make_id. 

    controller_id_t ID= make_id(destination,source,message Number);

MsgIdTmp is the message ID that you wanna receive. Bit 1 in mask means that certain bit you need to compare between MsgIdTmp and received message ID.


CAN message mask example

received message ID

[00,12,07]

MsgIdTmp

[20,12,31]

Mask

[00,FF,00]

Success

First mask data 00 means ignore the first data difference between received message ID and MsgIdTmp(ignore 00!=20).

Second mask data FF means you need to compare the second data. In this case both are 12, therefore, it passes the comparison

Third mask data is 00 (ignore 07!=20).

received message ID

[00,12,07]

MsgIdTmp

[20,12,31]

Mask

[00,FF,FF]

Failed

Third mask data is FF, so we need to compare 07 and 31. Apparently, 07 is not equal to 31, so the comparison is failed.


For example, there is a compass message comes from master. We can simply apply a filter as below 

   can2btptr->addMsgTamp(
           BluBeeTask_CAN2BT::MsgProp::gen(
                   make_id(0, cid_master_controller,
                           CAN_RX_DA_COMPASSSTATUS_MSG_ID), //Message ID templete
                   make_id(0,0xFFF,0xFFF)//Mask means don’t compare source section
                   , compassMSG));//Set Callback function compassMSG

We have a callback function “compassMSG” that can only receive compass messages and whichmessage was come from master controller. Since bridge controller receive this information, so we don’t need to compare destination. 

 bool compassMSG(BluBeeTask_CAN2BT *canbt, can_msg_t Msg)
 {
     sprintf(STRBUFF, "geo::%d,%d,%d,%d\r", (int16_t) Msg.data.words[0],
           (int16_t) Msg.data.words[1], (int16_t) Msg.data.words[2],
           (int16_t) Msg.data.words[3]);
     //convert those data into a string
     //notice the end of the string is ‘\r’, which is needed
     canbt->Send2BT(STRBUFF);// send to UART(Bluetooth)
     return true;
 }


Android Controller

  • Android platform receives the text data from bridge controller, then, transmit the data through ajax or websocket
  • External controller could be any TCP accessible device (simple pebble watch program (20 lines) are used to control start and stop)
  • One administrator(control and receive), multiple observers(only receive)
  • Number of way points and routing is dynamically determined and done using the Google Maps API


Bridge framework
cross platform


Intro
Intro
Intro
Intro


Implementation

Communication Bridge Communication Table
Message Number Purpose Data layout
0x528 Set Car Speed (Kill Switch) - temporary allow for other non-zero value for demo byte[0] - speed value
0x529 Destination GPS location

bytes [0-3] : latitude (float) bytes [4-7] : longitude (float)

0x52A Turn to degree

bytes [0-3] : degree(float)

0x52B Way points longitude 
bytes [0-1] :total waypoints count
bytes [2-3] :waypoint index
bytes [4-7] : longitude(float)
0x52C Way points latitude 
bytes [0-1] :total waypoints count
bytes [2-3] :waypoint index
bytes [4-7] : latitude(float)
0x52D remote status (ie. Android connection status) 
bytes [0]=>
0:disconnected(passive send)
1:on disconnect(active)
2:connected(passive)
3:on connect(active)
0xFF:error(active/passive)

Testing and Technical Challenge

TESTs

  • 100000 message(20bytes per message) Bluetooth transmission between board and android under 200fps with range <5m
    • 100% success

ISSUE

  • 3G network server could not be access(3G network is used for long range communication)
    • might use google sheet or external server to communicate

I/O Unit Controller

Group Members

Shreeram Gopalakrishnan
Sreeharsha Paturu Gangadhara

IO Team Schedule

Sl.No Start Date End Date Task Status Actual Completion Date
1 10/7/2014 10/13/2014 Research and Order LCD Display Ordered LCD Display 10/13/2014
2 10/14/2014 10/21/2014 Interfacing LCD Display with LPC1758 Completed 10/21/2014
3 10/21/2014 10/28/2014 Implementing CAN structure with LCD tasks. Completed 11/30/2014
4 10/28/2014 11/04/2014 Subscribe data from sensor and GPS controller,display it on LCD. Completed 11/08/2014
5 11/04/2014 11/11/2014 Setup hardware and write code for START, STOP and Headlight buttons. Completed 11/12/2014
6 11/11/2014 11/18/2014 Testing and mounting hardware on car. Completed 11/27/2014
7 11/18/2014 11/25/2014 Final Testing Completed 12/15/2014

Hardware Design

  • The IO Control Unit manages the LCD Display, switch to start and stop the car
  • It receives CAN data from the Master controller and accordingly processes to display on the LCD through UART
  • The 7 segment LED displays the CPU usage

LCD Display

  • The LCD Display is placed on the rear side of our RC Car
  • It displays the sensor and GPS values in real time.

CmpE243 F14 T3 LCD values.JPG

Hardware Interface

LCD hardware interface
I/O Controller Pin Connectivity Table
Description Your Device Port SJOne Development Board Port Commands Note
Supply Voltage 5V supply 
 Receives 5V supply that is used to power up all the boards
Ground GND GND
LCD Display 
 Rx pin
 Tx pin 

 Rx ---> TXD2 (Port 2.8)
 Tx ---> RXD2 (Port 2.9)

 u2.putline("F0")
 u2.putline("$CLR_SCR")
 u2.putline("$GOTO:3:0")

 Initialization command for LCD
 Clears the screen
 Point the cursor to line number 0 and character number 3
CAN Transceiver 
 Pin no. 1 Driver Input
 Pin no. 4 Receiver Output

 P0.1 CAN TD1
 P0.0 CAN RD1

Software Design

LCD Software Interface















Implementation

|Cmpe243.team3.IO FLOW.jpg

IO Communication Table
Message Number Purpose Data layout
0x102 Send boot status and version info bytes [0-2] : Status and version info
0x505 Display GPS and compass values 
Byte[0-1]: New Degree to Head
Byte[2-3]: Dist to Destination
Byte[4-5]: Current Degree value
0x506 Display Sensor Values 
Byte [0]: Front sensor value in inches
Byte [1]: Front Left sensor value in inches
Byte [2]: Front Right sensor value in inches
Byte [3]: Back sensor value in inches
Byte [4]: Speed value

Testing and Technical Challenge

LCD junk values

->Junk values being printed:

  • Although this error was not a show stopper, LCD printed junk values whenever it was on and any of the boards were programmed.
    • So, the only solution was to never program the board (connect the board to laptop) when LCD is on.

->Coding improvement

  • In the code, initially, the GPS, Sensor values were being printed in one line in the code. So, either the values were overwritten or there was shifting of those values. This was a synchronization issue.
    • Resolved it by, clearing each line in the LCD before printing it and used individual line in the code to print the values.

Conclusion

The whole project experience was fun and very educational. We learned about how CAN bus, sonar sensor, accelerometer sensor, light sensor, gps and compass module and motor controllers works. We faced some technical challenges such as controlling the motor speed, getting the right distance value from the sonar sensor, getting accurate readings from gps and compass and some of the power issues such as the right amount of current to the DC motors.

This project can be expanded to include more features such as an sonar sensor connected to the servo motor that rotates 360 degree to get distance from all the sides. This can reduce the number of sonar sensors. Furthermore, a improvement can be done in master and motor controller to control the car more precisely by controlling the car movement more accurately. A future suggestion would be to avoid non avoidable obstacles such as grass or follow only the planned route (may be be using some sensors or image detection).

Project Demonstration Video

Project Source Code

References

Acknowledgement

We would like to thank our instructor Preet for always inspiring and encouraging us to learn and build cool projects related to embedded systems. We really appreciate his patience and his guidance. This was our first exposure to CAN bus communication and we learned a lot about it. Last but not the least we would like to thank our awesome team members for supporting each other and helping each other out while working on this project.

References Used

http://www.ti.com/product/sn65hvd232

http://www.socialledge.com/sjsu/index.php?title=Self-driving_Car

http://www.nxp.com/documents/user_manual/UM10360.pdf

http://www.socialledge.com/sjsu/images/d/de/2012SJOneBoardSchematic.pdf

http://www.maxbotix.com/documents/MB1010_Datasheet.pdf

http://www.sharpsma.com/webfm_send/1208

https://www.sparkfun.com/datasheets/Components/HMC6352.pdf

http://www.seeedstudio.com/wiki/Bluetooth_Bee

http://www.adafruit.com/product/746

Retrieved from "http://socialledge.com/sjsu/index.php?title=F14:_Team3-Self_Driving_Car_-_Optimus_Prime&oldid=12381"