== Remote Learner ==

== Abstract ==
The objective of this project was to create a remote learner using the SJOne board. The Remote Learner would have the ability to be learn any buttons of any remote controller then controlled by an Android application using Bluetooth. The application would tell the SJOne board to learn a remote control button using the onboard IR receiver sensor. Once the button was learned, then the SJOne board notifys the Android application and allows the application to replicate the button functionality using our own IR transmitter.

== Objectives & Introduction ==
Project Remote Learner is to have the ability to learn button functionalities from multiple remotes, and then control devices via an Android application. The objects for the remote learner are as the following:
* To create an Android application that will communicate with SJOne board using Bluetooth and UART
* To create a task that will be signal by the Android application to learn the IR timing using the on-board IR receiver.
** Task will then send a message to Android application through a Queue to indicate if it was able to successfully capture and write the timing values to a file to Flash memory
* To create a task that will receive a signal to transmit the IR timing values from Flash memory. This task will use the PWM library and delay function to turn on and off the IR LED

=== Team Members & Responsibilities ===
* Ying (Bailey) Wu - Android App and BT I/F
* Yoni Klein - IR RX and IR Learning
* Tejeswar - IR Protocol
* Christopher Laurence - IR TX and IR learning

== Schedule ==
=== Remote Learner ===
{| class="wikitable"
|-
! scope="col"| Week
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Actual Completion Date
|-
|-
|1-2
|3/27/2015
|4/10/2015
|Research about the basic of remote controller protocols
|Completed
|3/10/15
|-
|-
|3
|4/10/2015
|4/17/2015
|Research about transmit timing of the protocol and analyze the data with a oscilloscope
Research about receive timing of the protocol and analyze the data with a oscilloscope
|Completed
|4/17/2015
|-
|-
|4
|4/17/2015
|4/24/2015
|Accurately decode IR signals from a remote control
Accurately transmit IR signals to a device
|Completed
|5/2/2015
|-
|-
|5
|4/24/2015
|5/1/2015
|Interface BT module and establish communication with the Android phone
Decide on a communication protocol between phone and board.
|Completed
|05/22/2015
|-
|-
|6-7
|5/1/2015
|5/15/2015
|Research and add additional protocol support
|Completed
|5/15/2015
|-
|-
|8
|5/15/2015
|5/22/2015
|Final integration and testing.
|Completed
|05/23/2015
|-
|}

=== Android Application ===
{| class="wikitable"
|-
! scope="col"| Week
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Actual Completion Date
|-
|-
|1
|4/6/2015
|4/13/2015
|Research about Android application development
Research about Bluetooth module implementation with SJOne board
|Completed
|4/10/2015
|-
|-
|2
|4/13/2015
|4/20/2015
|Implement and design a basic Android application on Android Studio
Implement the Bluetooth module using UART
|Completed
|4/27/2015
|-
|-
|3
|4/20/2015
|4/27/2015
|Continue development of the Android application
Establish a connection between the SJOne board and Android application through Bluetooth
|Completed
|5/04/2015
|-
|-
|4
|4/27/2015
|5/4/2015
|Collaborate with team members to integrate the Android application and remote learner functions
|Completed
|5/11/2015
|-
|-
|5
|5/4/2015
|5/11/2015
|Debug and troubleshoot any issues that may arise
|Completed
|5/23/2015
|-
|-
|6
|5/11/2015
|5/18/2015
|Miscellaneous
|Completed
|5/23/2015
|-
|-
|}

== Parts List & Cost ==
Give a simple list of the cost of your project broken down by components. Do not write long stories here.
{| class="wikitable"
|-
! scope="col"| Line Item#
! scope="col"| Part Desciption
! scope="col"| Vendor
! scope="col"| Part Number
! scope="col"| Qty
! scope="col"| Cost ($)
|-
! scope="row"| 1
| 120 Resistor
| Anchor Electronic
| N/A
| 10
| 1.00
|-
! scope="row"| 2
| IR LED 1.5 V 40mA
| Anchor Electronic
| N/A
| 4
| 1.00
|-
! scope="row"| 3
| HC-06 Bluetooth Module
| N/A
| N/A
| 1
| 9.99
|-
! scope="row"| 4
| SJOne
| N/A
| N/A
| 1
| 80.00
|}

== Design & Implementation ==
=== Hardware Design ===
====Transmit IR LED:====
The IR LED transmitter is a simple circuit that connects to a PWM pin that is set to toggle at 38 Khz. The circuit needs a resister to create the voltage drop for the IR LED.
 
[[File:CmpE244_S15_T3_Remote_Learner_IR LED Circuit.png|600px|centre|thumb|IR LED circuit]]

 

====Receive IR LED:====
The IR receiver is already part of the SJOne board. On our revision 4 board, this is the TSOP75238TR IR Receiver Module by Vishay Semiconductors. Other revision boards may have a slightly different part, but the operation and concepts are the same.
[[File:S15_244_RemoteLearner_IR_Receiver.png|400px|centre|thumb|IR Receiver Circuit]]
 
The basic circuit is relatively simple. Along with power and ground, an output signal is connected to two different parts of the board.

The first connection is made to P1[18] on the LPC controller. This GPIO pin will be configured to use the capture feature of the boards timer in order to "capture" the time a rising or falling signal event occurs. This pin is labeled as "IR_DATA" on the board schematic and the associated GPIO function is referred to as CAP1[0] in the user manual.
The operation of the capture pin is described in the Hardware Interface section below.

[[File:S15_244_RemoteLearner_IR_Receiver_LPC_Input.png|600px|centre|thumb|IR_DATA connection to CAP1[0]]]

The second connection is to an external pin referenced in section 6D on page 3 of the board schematic. This is mainly used for debugging and validating captured data on an oscilloscope. Thanks Preet for adding this! Both of these connections are displayed in the images below.

[[File:S15_244_RemoteLearner_IR_Receiver_Test_Pin.png|365px|centre|thumb|External Pin]]

====Android Application with SJOne Board Hardware Design ====
The Android application hardware design consists of the Bluetooth module (HC-06) and SJOne board. The communication link is established using the SJOne board UART3 Tx and Rx Pins.

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

====PWM to IR Transmitter LED:====
The PWM was used to generate the 38 Khz by creating an instance of PWM class. Then using the predefined function of "pwm.set" to toggle the pin at a duty cycle of about 25% and after certain amount of time we set the duty cycle to 0. Below is the standard behavior for NEC IR protocol explaining the amount of time that the PWM pin needs to toggle and time required to be off.

{| class="wikitable"
|-
! scope="col"| Protocol
! scope="col"| On(µs)
! scope="col"| Off(µs)
! scope="col"| Total(µs)
|-
! Start
| 9000
| 4500
| 13500
|-
! 0 bit
| 560
| 560
| 1120
|-
! 1 bit
| 560
| 1690
| 2250
|-
! End
| 560
| N/A
| 560
|}

[[File:CmpE244_S15_T3_Remote_Learner_NEC_IR.JPG|600px|centre|thumb|In the above image is a capture of a NEC IR transmission using an oscilloscope.]]
 

====IR Receiver to Capture Pin:====
The IR receiver outputs a logic one (high, 3.3v) signal when idle. When active, the signal drops to a logic zero (low, 0v). Therefore, the signal is active low, which may actually be inverted relative to the transmitted signal. The images below show two examples of transmitted signals and receiver output.

{| style="width:1200px;" |
|[[File:S15_244_RemoteLearner_IR_Receiver_Waveform1.png|400px|center|thumb|IR receiver output given typical pulse input signal]]
|[[File:S15_244_RemoteLearner_IR_Receiver_Waveform2.png|400px|center|thumb|IR receiver output given pulse burst input signal]]
|}

These images are from the IR receiver data sheet included in the development package of the SJOne board. However, you can find it on Vishay's website as well. This signal is physically connected to one of the capture pins on the LPC microcontroller. In our example, the board is designed to take this input on P1[18] using CAP1[0].

The capture feature is associated with one of the boards timers. In our case, this is timer 1 (hence CAP1). The [0] indicates port 0. Timer 1 is used by the development package, so it should already be started for us. All we need to do is configure the Capture Control Register to generate an input on both rising and falling edges.

When this interrupt occurs, we get a tick count. We don't need to know the time exactly, just the difference in times between captures. Since the IR receiver idles high, we know the first interrupt will be for a falling edge. We can perform the calculations according to this assumption.

=== Software Design ===
Show your software design. For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code. For example, do not show exact code, but you may show psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.

====IR Receive Task====

There are two components that make the IR receive functionality work. The first is the task itself, which processes commands from the Bluetooth task and saves IR timings to the SD card.

''The receive task and capture code was modified from Preet's IR_Sensor and remoteTask classes. This was a great starting place but needed to be modified to suit the project needs.''

This task sleeps indefinitely until it receives a message on the mRXQueue. If this message contains a learn command, it will attempt to take the mutex shared by the transmit task. If it can take it, that means the system is not transmitting and it's safe to start recording timing signals. If it can't take it, then the task will let the Bluetooth task know the system is busy and cannot learn new commands.

However, if learning can continue, we signal the second part of the IR receive functionality. We tell the IR_Sensor singleton class to clear any stored captures and wait until a new command is received or a timeout occurs. Next, we retrieve the array of timings and store it on the SD card for the transmit task to use.

The code segment and flow chart to show this behavior are shown below.
 
<syntaxhighlight lang="c">
bool remoteRXTask::run(void *p)
{
u0_dbg_printf("Learning...\n" );
//Receive item from queue
xQueueReceive(rxQueue);
//Check if it is a learn command and semaphore avaliable
if ((learn_command) && (xSemaphoreAvaliable))
{
//Read IR code
IS.clearCode();
while(!IS.isIRCodeReceived())
{
vTaskDelayMs(100);
}
uint8_t max_timings = 255;
uint16_t timings[max_timings] = {0};
uint16_t count;
IS.getLastIRCode(timings, &count, max_timings);
//get+store the code and send feedback here
sprintf(filename,"1:%c.hex",mMsg.button);
Storage :: write(filename,(void *)&timings,count,0);
xSemaphoreGive(mIRMutex);
}
else
{
strcpy(mMsg.msg,"*****Busy Transmitting***");
//Send item to the Bluetooth queue
xQueueSend(mBtQueue,&mMsg,0);
}
return true;
}
</syntaxhighlight>
 
[[File:S15_244_RemoteLearner_IR_Receiver_TaskFlow.png|700px|center|Flow Diagram for IR receive Task|thumb|Flow Chart : IR Receive Task]]
 
The code below is the core of what makes the IR learning possible. If a rising or falling edge occurs on the capture pin, then an interrupt is generated. In this case, storeIrCode() will be called which saves the timestamps to an array. We set a timeout of 50ms, after which decodeIrCode() is called that calculates the differences in timestamps. These differences are the timings we will store and later transmit.

The 50ms timeout was chosen because some remotes have more complicated commands that include two consecutive commands. The time between those commands was measured to be about 40ms with the tested remotes.
<syntaxhighlight lang="c">
#if (1 == SYS_CFG_SYS_TIMER)
/* ISR for captured time of the capture input pin */
if (intr_reason & timer_capt0_intr_ir_sensor_edge_time_captured)
{
gp_timer_ptr->IR = timer_capt0_intr_ir_sensor_edge_time_captured;
// Store the IR capture time and setup timeout of the IR signal (unless we reset it again)
IS.storeIrCode(gp_timer_ptr->CR0);
//10k was too short of a timeout for long commands,
//which sometimes have separations of up to 40ms
gp_timer_ptr->MR2 = 50000 + gp_timer_ptr->TC;
}
/* MR2: End of IR capture (no IR capture after initial IR signal) */
else if (intr_reason & timer_mr2_intr_ir_sensor_timeout)
{
gp_timer_ptr->IR = timer_mr2_intr_ir_sensor_timeout;
IS.decodeIrCode();
}
/* MR0 is used for the timer rollover count */
else
#endif
</syntaxhighlight>
 
<syntaxhighlight lang="c">
void IR_Sensor::storeIrCode(uint32_t value)
{
if (!m_ready_to_receive)
return;
// Just store the timestamp of this signal
if(g_signal_count < MAX_EDGES_PER_IR_FRAME)
{
g_ir_edge_timings[g_signal_count++] = value;
}
}
</syntaxhighlight>
 

<syntaxhighlight lang="c">
void IR_Sensor::decodeIrCode(void)
{
if (!m_ready_to_receive)
return;
for (int i = 0; i < g_signal_count-1; i++)
{
g_ir_cmd_timings[i] = g_ir_edge_timings[i+1]-g_ir_edge_timings[i];
}
m_code_received = true;
m_ready_to_receive = false;
}
</syntaxhighlight>
 

[[File:S15_244_RemoteLearner_IR_Receiver_CaptureFlow.png|500px|center|Flow Diagram for IR capture|thumb|Flow Chart : IR Capture Interrupt]]

====IR Transmit Task:====
 
The IR transmit task will be signaled by the Bluetooth task. After being signal the task will attempt to read from a file using the Storage class. If the file doesn't exist it will send an error message the terminal. If the file does exist then the task will read all the timing values into an array. The task will then enter a PortCritical area and transmit the IR signal by turning on and off the PWM pin. Once it is finished the IR Transmit task return the Mutex.
 
<syntaxhighlight lang="c">
remoteTXTask(uint8_t priority) :scheduler_task("rTX", 2048, priority), pwm0(38Khz)
bool run(void *p)
{
xQueueReceive;
if ((command == send_cmd) && xSemaphoreTakeAvailable)
{
u0_dbg_printf("Transmitting...\n" );
int size = readFile(mMsg.fileName);
portENTER_CRITICAL();
for(int i = 0; i < size; i++)
{
if(i % 2 == 0) pwm1.set(25);
else pwm1.set(0);
delay_us(timing_values[i]);
}
pwm1.set(0);
portEXIT_CRITICAL();
}
xSemaphoreGive(mIRMutex);
return true;
}
</syntaxhighlight>
[[File:CmpE244_S15_T3_Remote_Learner_IRTask.jpg|250px|center|Flow Diagram for IR transmit Task|350px|thumb|Flow Chart : IR Transmit Task]]

====Android Application with SJOne Board Software Design ====

[[File:CMPE244_S15_TEAM2_Android_FlowChart.png|300px|right|thumb|Flow Chart: Android App with SJOne Board Software Design]]

The Android application Bluetooth task is to provide the a communication link between all the tasks. The Bluetooth task would receive commands from the application, then send items to the queue with the appropriate information such as command, button number, and message from the Android application.

 
'''Pseudo Code:'''
<syntaxhighlight lang="c">
void BluetoothTask(void *p) {
//Initialize transmit, receive and bluetooth queues
bool init();
bool run()
{
//Get command from Android app
uart3.gets();
//Check if it is a transmit or learn command
checkCommand();
//Send item to the appropriate queue
xQueueSend();
//Sleep to reduce CPU usage
vTaskDelay(10);
}
}
</syntaxhighlight>

 

=== Remote Learner Android App ===
The software development environment for the Remote Learner android application is Android Studio 1.2.1.1.

[[File:CMPE244_S15_TEAM2_Android_AndroidStudio.png|900px|center|thumb|Android App: Development Envirnoment]]
 
 

{| style="width:1200px;" |
|[[File:CMPE244_S15_TEAM2_Android_Unconnected.png|350px|left|thumb|Android App: Starting Screen]]
|[[File:CMPE244_S15_TEAM2_Android_DeviceList.png|350px|left|thumb|Android App: Bluetooth Device List]]
|[[File:CMPE244_S15_TEAM2_Android_Connecting.png|350px|left|thumb|Android App: Connecting to Bluetooth Device]]
|}
 

{| style="width:1200px;" |
|[[File:CMPE244_S15_TEAM2_Android_Connected.png|350px|left|thumb|Android App: Bluetooth Device Connected]]
|[[File:CMPE244_S15_TEAM2_Android_Learned.png|350px|left|thumb|Android App: Button Learned]]
|[[File:CMPE244_S15_TEAM2_Android_LearnFailed.png|350px|left|thumb|Android App: Button Learn Failed]]
|}

 

== Testing & Technical Challenges ==
Describe the challenges of your project. What advise would you give yourself or someone else if your project can be started from scratch again?
Make a smooth transition to testing section and described what it took to test your project.

Include sub-sections that list out a problem and solution, such as:

=== IR Transmit Issue #1 ===
'''PROBLEM:'''

IR transmission signal was not being received by IR receiver.

'''RESOLUTION:'''

Used Oscilloscope to discover that PWM instance set to 38,000 Hz did not produce a 38 kHz. Had to adjust the value to about 3205 Hz to get a PWM signal that was about 38Khz.

'''FUTURE RECOMMENDATIONS:'''

Examine PWM code and determine if there is a way to enter the fequency in Khz.

=== IR Transmit Issue #2 ===
'''PROBLEM:'''

Putting IR transmission signal in task was causing IR signal not to be received because task was being interrupted.

'''RESOLUTION:'''

Placed time sensitive code in a Port Critical section to prevent that section of code being interrupted.

=== IR Transmit Testing ===
To test the IR transmitter we first used an oscilloscope to capture a IR signal from a remote control. After capturing the signal we determined the protocol. To replicate the signal we created an array with the timing values. The array values that were even index values represented the timing for the IR led to toggle on. The odd values represent the timing values that the IR LED need to be off. Using a for loop, we send the signal and tested using an oscilloscope first. After determining that the signal was similar to the capture, we tested with a few devices. The first device was an Apple remote to turn the volume up. Afterward we tested a different device using a different protocol. We were able to figure channel up/down and volume up/down and control a Sharp TV. The final test for integration was to control an LG TV. See demo video of the device controlling LG TV.

=== Android App Testing ===
This section is for android app testing.

== Conclusion ==
Conclude your project here. You can recap your testing and problems. You should address the "so what" part here to indicate what you ultimately learnt from this project. How has this project increased your knowledge?

=== Project Video ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_SJSU_S2015/ Sourceforge Source Code Link]

== References ==
=== Acknowledgement ===
Any acknowledgement that you may wish to provide can be included here.

=== References Used ===
List any references used in project.

=== Appendix ===
You can list the references you used.

File:S15 244 RemoteLearner IR Receiver CaptureFlow.png

2015-05-24T18:31:14Z

146S12T4:

2014-12-23T03:49:53Z

146S12T4: /* IO Task */

== Self Driving Car ==

== Objective and Scope ==

[[File:CmpE243_F14_SelfDrivingCarT5_system_diagram.jpg|400px|thumb|right|Fig 2. System Block Diagram]]
This project is aimed at creating a self-driving car with obstacles avoidance and to steer to the gps location pointed by the android application with the help of multiple controllers communicating using CAN bus.CAN(Control Area Network) is a communication protocol used widely in automotive application developed by BOSCH in 1986. The self-driving car consists of 6 different controllers for '''GPS''','''Sensor''','''Central''','''Motor''','''IO''' and '''Communication'''. The controllers communicate to other controller by CAN bus.We have implemented broadcast algorithm to broadcast all the data from each controller in different frequencies. The controller parses the data using the 29 bit identifier which has destination and source address.

== Team Members & Responsibilities ==

{| class="wikitable"
|-
! scope="col"| Sl. No
! scope="col"| Task
! scope="col"| Team Members
|-
! scope="row"| 1
| Sensor Controller
|
# Bailey Wu
# Rishabh Sareen
# Rishab H
|-
! scope="row"| 2
| Motor Controller
|
# Abhraham Ruiz
# Arpit Amin
# Sree Harsha
|-
! scope="row"| 3
| I/O Controller (LCD Display)
|
# Yoni Klein
# Tejeswar
|-
! scope="row"| 4
| Communication Bridge + Android
|
# Shaw Ken Chang
# Arnold Bajet Jr.
# Thomas Pantels
|-
! scope="row"| 5
| Geographical Controller
|
# Himanshu Saini
# Divya Kamath
|-
! scope="row"| 6
| Central Controller
|
# Divya Kamath
# Tejeswar
# Sree Harsha
|-
! scope="row"| 7
| Car design and wiring
|
# Bailey Wu
# Himanshu Saini
# Sree Harsha
# Karthik Vadiraja
# Akash Ayare
|-
! scope="row"| 8
| Git Setup
| Akash Ayare
|-
|}

== Introduction ==

The goal of this project was to design and implement a self-driving car. The team consisted of 15 people, divided into 6 teams corresponding to six controllers. The aim of this class was to understand the CAN protocol that is used extensively in vehicles. The self-driving car houses six controllers, all of them communicating using CAN. Each controller performs a unique task such as:
# '''Sensor Controller''': Interfaced to the front and back sensors. Periodically sends sensor data to the central controller. Crucial for obstacle detection and avoidance
# '''Motor Controller''': Controls the motors and steering of the car, based on commands received from central controller.
# '''Geographical Controller''': Interfaced to GPS and compass. Periodically sends location, heading and distance from destination. crucial for autonomous navigation of the car.
# '''Communication Controller''': Acts as a bridge for Android. Android app is used to set destination, calculate path to destination, start and stop the car. Data is sent to central and geographical Controller based on user input.
# '''Central Controller''': The brain of the car. Uses sensor and geographical data to steer the car in the right direction. Uses sensor data to detect and avoid obstacles. Uses geographical data to move towards desired location
# '''Display Controller''': Interfaced to an LCD screen which displays status of the car (reached/ not reached), CAN bus utilization, sensor data, bearing, heading etc.

== Schedule ==

'''Geographical Controller'''

{| class="wikitable"
|-
! scope="col"| Sl. No
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Actual Completion Date
|-
! scope="row"| 1
| 1-Oct-2014
| 14-Oct-2014
| Order Components and Make a schedule
| Completed
| 14-Oct-2014
|-
! scope="row"| 2
| 8-Oct-2014
| 14-Oct-2014
| Decide commands that Geographical Controller will support
| Completed
| 14-Oct-2014
|-
! scope="row"| 3
| 7-Oct-2014
| 14-Oct-2014
| Complete CAN RX task and subscription handling. Verify communication with other controllers
| Completed
| 21-Oct-2014
|-
! scope="row"| 4
| 14-Oct-2014
| 24-Oct-2014
| Interface GPS module and Compass and develop drivers if needed
| Completed
| 28-Oct-2014
|-
! scope="row"| 5
| 24-Oct-2014
| 30-Oct-2014
| Design and develop algorithm to calculate heading and bearing from GPS coordinates
| Completed.
| 30-Oct-2014
|-
! scope="row"| 6
| 24-Oct-2014
| 5-Nov-2014
| Work on calibration of compass and heading calculation
| Completed
| 11-Dec-2014
|-
! scope="row"| 7
| 1-Nov-2014
| 10-Nov-2014
| Test with the central and Bluetooth controller
| Completed
| 14-Dec-2014
|-
! scope="row"| 8
| 10-Nov-2014
| 25-Nov-2014
| Begin testing with fully assembled car
| Completed
| 1-Dec-2014
|-
|-
! scope="row"| 9
| 25-Nov-2014
| 10-Dec-2014
| Final Testing and changes as needed
| Completed
| 19-Dec-2014
|-
|}

'''Sensor Controller'''

{| class="wikitable"
|-
! scope="col"| Sl. No
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Actual Completion Date
|-
! scope="row"| 1
|10/3/2014
|10/10/2014
|Order ultrasonic sensor parts and develop simple test code for the sensors
|Done
|10/10/2014
|-
! scope="row"| 2
|10/10/2014
|10/17/2014
|Wire the ultrasonic sensors, develop and implement the sensors using analog to digital converter
|Done
|10/17/2014
|-
! scope="row"| 3
|10/17/2014
|10/24/2014
|Collaborate with the other sub teams to finish the CAN bus communication and allow the self driving car to drive autonomously
|Done
|10/24/2014
|-
|! scope="row"| 4
|10/24/2014
|11/1/2014
|Develop, implement and test the ultrasonic sensors using the pulse width modulation and universal asynchronous receiver/transmitter
|Done
|11/1/2014
|-
! scope="row"| 5
|11/2/2014
|11/9/2014
|Develop, implement and test the front and back infrared sensors using analog to digital converter
|Done
|11/9/2014
|-
! scope="row"| 6
|11/10/2014
|11/17/2014
|Develop, implement and test the current/voltage sensor for the battery packs of the self driving car using I2C
|Scheduled
|Removed
|-
! scope="row"| 7
|11/18/2014
|11/25/2014
|Collaborate with the other sub teams to make sure that the sensors are in working condition
|Done
|11/25/2014
|-
|-
! scope="row"| 8
|11/26/2014
|12/5/2014
|Collaborate with the other sub teams to debug any problems that may encountered
|Done
|12/5/2014
|-
! scope="row"| 9
|12/6/2014
|12/13/2014
|Prepare for demo
|Done
|12/19/2014
|-
|}

'''IO Controller'''

{| class="wikitable"
|-
! scope="col"| Sl. No
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Actual Completion Date
|-
|-
! scope="row"| 1
|10/7/2014
|10/14/2014
|Research and order LCD appropriate for this project
|Done
|10/11/2014
|-
|-
! scope="row"| 2
|10/7/2014
|10/17/2014
|Implement CAN RX/Subscription task
|Done
|10/13/2014
|-
|-
! scope="row"| 3
|10/7/2014
|10/17/2014
|Finalize Task Architecture
|Done
|11/1/2014
|-
|-
! scope="row"| 4
|10/18/2014
|10/21/2014
|Interface and test LCD
|Done
|10/20/2014
|-
|-
! scope="row"| 6
|10/21/2014
|10/28/2014
|Implement auto scrolling feature
|Done
|11/18/2014
|-
|}

'''Communication Bridge + Android'''

{| class="wikitable"
|-
! scope="col"| Sl. No
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Actual Completion Date
|-
! scope="row"| 1
| 16-Sep-2014
| 23-Sep-2014
| Test bluetooth module using computer serial port and an android app(simple bluetooth terminal app downloaded from google play). Test the real life range and stability of the bluetooth module (HC-06). Modify the bluetooth chat example to work with the bluetooth module.
| Done
| 20-Sep-2014
|-
! scope="row"| 2
| 28-Sep-2014
| 12-Oct-2014
| Draw UI design layouts for a basic android application that can view Google map as well as send GPS data through bluetooth by clicking on the map. Study google maps API and make a simple app that will post a short toast that shows the GPS location after a long press event.
| Done
| 12-Oct-2014
|-
! scope="row"| 3
| 7-Oct-2014
| 11-Oct-2014
| Interface bluetooth module with SJSUOne board and able to verify that the connection is stable and that transaction via the bluetooth is accurate. This is done by adding a test button where if you press the button it send a command to the board. After receiving the command, the board should react with a response (LED light and/or text response to the android phone)
| Done
| 19-Oct-2014
|-
! scope="row"| 4
| 11-Oct-2014
| 19-Oct-2014
|Integrate Google Maps and Bluetooth component together in Android app. After a long press on the map, the user should be prompted to start the car and set the location as the places the user selected. Add a textView to display the location selected by pressing on the map. Add a button for sending location to the car.
| Done
| 27-Oct-2014
|-
! scope="row"| 5
| 19-Oct-2014
| 26-Oct-2014
| CAN infrastructure implmentation: Use our team's common CAN infrasturcture code and modify it specifically for our controller. First created the CAN communication table and then modify the infracturacture code to implement the broacasting as well as filtering of neccessary data. This only focuses on broadcasting a stop/start command and the destination GPS data (set by android) as well as getting car's current location data from the geological controller.
|Done
| 07-Nov-2014
|-
! scope="row"| 6
| 26-Oct-2014
| 1-Nov-2014
| Test and implement car information reading as well as other functions of Android app
| In Progress
|
|-
! scope="row"| 7
| 2-Nov-2014
| 4-Nov-2014
| Iterate UI design
| In Progress
|
|-
! scope="row"| 8
| 5-Nov-2014
| 16-Nov-2014
| Implement 2nd UI design
| In Progress
|
|-
|}

'''Motor Controller'''

{| class="wikitable"
|-
! scope="col"| Sl. No
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Actual Completion Date
|-
|-
! scope="row"| 1
|10/1/2014
|10/8/2014
|PWM2 (used to control motors) and PWM3 (used to control servo) interface with the car servo and motor. Write a test code to operate the servo and motor from the terminal command.
|Completed and Tested
|10/11/2014
|-
|-
! scope="row"| 2
|10/9/2014
|10/18/2014
|Design and code CAN receive task for subscription. Check for basic CAN message commands for throttle and steer control.
|Completed and tested
|10/26/2014
|-
|-
! scope="row"| 3
|10/19/2014
|10/28/2014
|Design the CAN message table for motor control and servo control
|Completed and tested
|10/26/2014
|-
|-
! scope="row"| 4
|10/29/2014
|11/07/2014
|Design acceleration Vs steer control function for smooth run. Check for other factors involved.
|Completed and tested
|11/22/2014
|-
|-
! scope="row"| 5
|11/08/2014
|11/14/2014
|Research on RPM sensor. Interface the RPM sensor to calculate the Speed. Test the RPM sensor by running the car at different speed
|Completed and tested with a hall sensor
|11/22/2014
|-
|-
! scope="row"| 6
|11/15/2014
|11/21/2014
|Fine tune motor control code and integrate with all the controllers for proper working.
|Completed and tested
|11/22/2014
|-
|-
! scope="row"| 7
|11/22/2014
|11/28/2014
|Test and check if more features can be added to improve performance. Completed and tested
|Completed and tested
|11/28/2014
|-
|-
! scope="row"| 8
|11/29/2014
|12/05/2014
|Testing and Debugging.
|Completed and tested
|12/05/2014
|-
|-
!scope="row"|9
|12/06/2014
|12/18/2014
|Final Testing and getting the car ready for Demo.
|On Going
|

|}
'''Central Controller'''

{| class="wikitable"
|-
! scope="col"| Sl. No
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Actual Completion Date
|-
! scope="row"| 1
| 16-Sep-2014
| 23-Sep-2014
| Develop API for CAN bus communication.
| Done
| 23-Sep-2014
|-
! scope="row"| 2
| 11-Oct-2014
| 15-Oct-2014
| Develop communication table for all controllers.
| In Progress
|
|-
! scope="row"| 3
| 15-Oct-2014
| 20-Oct-2014
| Broadcast message and target message setup.
| Done
|
|-
! scope="row"| 4
| 21-Oct-2014
| 28-Oct-2014
| Co-ordinate all controllers and take major decisions.
| Done
|
|-
! scope="row"| 5
| 28-Oct-2014
| 11-Nov-2014
| Complete Building and fine-tuning of RC car.
| In Progress
|
|-
! scope="row"| 6
| 21-Oct-2014
| 11-Nov-2014
| Develop coordination mechanism to ensure controllers are initialized and ready
| In Progress
|
|-
! scope="row"| 7
| 21-Oct-2014
| 28-Oct-2014
| Develop kill switch
| Done
|
|-
! scope="row"| 8
| 14-Oct-2014
| 21-Oct-2014
| Build external power distribution circuit
| Done
| 21-Oct-2014
|-
! scope="row"| 9
| 28-Oct-2014
| 04-Nov-2014
| Coordination algorithm between steering and throttle for smooth turns
| In Progress
|
|-
! scope="row"| 10
| 04-Nov-2014
| 11-Nov-2014
| Collision avoidance algorithms
| Done
|
|-
! scope="row"| 11
| 04-Nov-2014
| 11-Nov-2014
| Intermediate unit and functional tests
| In Progress
|
|-
! scope="row"| 12
| 11-Nov-2014
| 25-Nov-2014
| Functional tests and algorithm adjustments
| In Progress
|
|-
! scope="row"| 13
| 25-Nov-2014
| 02-Dec-2014
| Fine tuning and stretch goals (headlights, parallel parking, etc.)
| Done
|
|-
! scope="row"| 14
| 02-Dec-2014
| 09-Dec-2014
| Prepare for demo
| In Progress
|
|-
|-

|}

== Parts List & Cost ==

{| class="wikitable"
! width="350" align="center"|Description
! width="30" align="center"|Qty
! width="60" align="center"|Price
|-
| LV-MaxSonar-EZ1 High Performance Ultrasonic Rangefinder
| 2
| 49.90
|-
| Analog Distance Sensor
| 1
| Free
|-
|1/10 Scale 4x4 Truck with Brushed Motor
|1
|217.33
|-
|2 ft 12-Gauge Power Cables
|3
|22.80
|-
|Pair Power Socket
|2
|2.16
|-
|Standard Size Body Clips
|12
|2.16
|-
|4-pack AA Batteries
|1
|3.45
|-
|50-pack M3x15mm Stand-Off Spacer Female-Male
|1
|11.19
|-
|100-pack 18-8 Flat Steel Washer
|1
|2.54
|-
|100-pack M3x20mm Hex-Drive Screw
|1
|6.47
|-
|100-pack M3 Steel Hex Nut
|1
|4.66
|-
|2-pin JST Connector Right Angle
|10
|6.84
|-
|4-pin JST Connector Right Angle
|10
|6.84
|-
|2-pin Female JST Cable (20 cm)
|10
|7.39
|-
|4-pin Female JST Cable (20 cm)
|10
|7.39
|-
|5 Volt Relay Breakout Board
|1
|4.95
|-
|5 Volt Voltage Regulator
|1
|1.07
|-
|Sharp Analog Distance Sensor 4-30 cm
|1
|9.95
|-
|3-pin Female JST PH-Style Cable (30 cm)
|1
|0.92
|-
|Double Sided Mounting Tape - 3 feet
|1
|4.35
|-
|AC Adapter (LiPo Charger)
|1
|15.16
|-
|IEC Power Cable (LiPo Charger)
|1
|5.38
|-
|4mm Bullet Plugs to Universal Plug
|1
|13.38
|-
|Acrylic sheet + Sharpe mini
|1+1
|11.72
|-
|Molex Pin Header, Connector, wires and 100 zip ties
|10+4+1
|17.13
|-
|2 x 90 degree pin header, 2 x straight pin header
|2+2
|3.65
|-
|uni-polar hall sensor for tachometer feedback
|2
|2.18
|-
|Heavy Duty magnets
|2
|4.18
|-
|INA219 Voltage sensors 26V +/-3.2A
|2
|19.9
|-
|-
|20x4 Serial LCD Module
|1
|29.99
|-
|}

== Backup Parts & cost ==

{| class="wikitable"
! width="30" align="center"|Qty
! width="350" align="center"|Description
! width="110" align="center"|Manufacturer
! width="60" align="center"|Part Number
! width="60" align="center"|Total Cost
|-
| 1
| LV-MaxSonar-EZ1 High Performance Ultrasonic Rangefinder
| MaxBotix Inc
| MB1010
| Free
|-
| 1
| Analog Distance Sensor
| Sharp
|
| Free
|-
|}

== Design & Implementation ==
[[File:CmpE243_F14_Team5_OverallHWDesign.jpg]]

== Motor Controller ==

==== Summary ====
This module takes command input from central controller and steers the car to its destination; in addition, It has two main controlling parameters : Throttle and Steering. Throttle input moves the car forward and backward. Steer input turns the wheel left and right. The central controller takes feedback from the sensors and makes decision to move the car. Accordingly, it sends CAN commands accepted by the motor controller for navigation, and real time RPM signal to the controller.

{| class="wikitable"
|+ Motor and Steer control : Technical Information
|-
! width="30" align="center"|Sl.No
! width="90" align="center"|Controller
! width="90" align="center"|Signal Type
! width="90" align="center"|Frequency
! width="350" align="center"|Functionality
|-
! scope="row"|1
| Motor Control
| PWM signal
| 50 Hz (20000us)
| 1000us (Full throttle forward) - 1500us (Stop) - 2000us (Full throttle backward)
|-
! scope="row"|2
| Steer Control
| PWM signal
| 50 Hz (20000us)
|1000us (Turn left max) - 1500us (Center) - 2000us (Turn right max)
|-
|}

===== Working =====
The car initially accepts the start command to begin navigation. Commands can then come to move the car forward or backward, steer left or right depending on intelligent decisions made by the central controller. The motor control has intelligence to avoid jerks and ensure smoother transitions between commands. The central controller gets the data from the sensors for obstacle avoidance. The car has a communication controller which gets the '''GPS''' data from the android application, the android application sets the destination latitude and longitude. The car decides the heading direction by the gps points and the compass and if it finds obstacle it will be controlled by the obstetrical avoidance and steer to the destination according to the algorithm below.
===== Flow Chart =====

[[File:Cmpe243_F14_T5_motor_controller_flowchart1.png]]

===== Kill switch =====
The remote control and receiver module pair up to provide a signal coverage of more than 100 meters. We make use of this to design our kill switch. When a constant PWM signal of 1000us is received from the remote, the car is in 'ARMED' state and moves the car according to CAN commands. The user has to hold the trigger gun for this state constantly and the car moves.
When the user releases the trigger gun, the car stops receiving the PWM signal of 1000us and the car goes to 'DISARMED' state.
In short, pull the trigger gun - ARMED, release the trigger gun - DISARMED.

===== RPM =====
The RPM sensor is based on a hall sensor switch which detect the North and South pole of a magnet located in the main shaft in the car. The hall sensor part number is 3177, and it has three pin. This sensor is uni-polar which give an output high signal when the sensor captures the North pole of the magnet; subsequently, the sensor give output low signal when the sensor captures the South pole of the magnet. Therefore, by using a the 3177 and a magnet in the shaft. the SJOne board can capture the output signal from the hall sensor as it toggles per shaft revolution.
It is important to notice that the output signal of the 3177 is an open collector; therefore, we need a 10 Kohm resistor connected to Vcc.

===== Pinout Table =====

The following table shows the pinout of all component that are connected to SJONE board.

{| class="wikitable"
|-
! scope="col"|No
! scope="col"|Description
! scope="col"|Component Pin
! scope="col"|Output Pin Source
|-
! scope="row"|1
|Hall Sensor (3177) Vcc ( 4.5 V to 18 V)
|Source
|SJOne P1_22
|-
! scope="row"|2
|Hall Sensor (3177) Ground
|Ground
|SJOne
|-
! scope="row"|3
|Hall Sensor (3177) Output
|Output
|SJOne P1_22 with a 10 KOhm
|-
!scope ="row"|4
|CAN Transceiver
|Pin # 1 TX
|SJOne P0_1(Tx)
|-
!scope ="row"|5
|CAN Transceiver
|Pin # 2 GND
|SJOne GND
|-
!scope ="row"|6
|CAN Transceiver
|Pin # 3 VCC
|SJOne 3.3v
|-
!scope ="row"|7
|CAN Transceiver
|Pin # 4 RX
|SJOne P0_0(Rx)
|-
!scope ="row"|8
|CAN Transceiver
|Pin # 6 CANL
|CAN Bus
|-
!scope ="row"|10
|CAN Transceiver
|Pin # 7 CANH
|CAN Bus
|-
!scope ="row"|11
|Servo
|VCC
|5V Power Rail
|-
!scope ="row"|12
|Servo
|GND
|GND Power Rail
|-
!scope ="row"|13
|Servo
|Signal
|PWM 2.1
|-
!scope ="row"|14
|Electric Speed Control (ESC)
|VCC
|5V Power rail
|-
!scope ="row"|15
|Electric Speed Control (ESC)
|GND
|GND Power Rail
|-
!scope ="row"|16
|Electric Speed Control (ESC)
|Signal
|PWM 2.2
|}

===== Block Diagram =====
The following Block diagram shows an overview of the connection between the SJOne board, ESC, and the Hall sensor:

[[File:Motor Block Diagram 1.jpg|600px|thumb|center|Motor Controller Block Diagram]]

== Sensor Controller ==
===Sensor Controller Hardware Design and Architecture ===

The figure below shows how all the sensors are inter-connected to the SJOne board and CAN bus. The sensors are connected to +5V to achieve the highest beam pattern that is available. The back infrared sensor is also connected to the +5V power source to obtain the longest range detection possible. Most important, the SJOne board is connected to the CAN bus to broadcast the available data to the rest of the controllers in the system.

[[File:CmpE243_F14_T5_SensorHWDesign.JPG|700px|thumb| center |Fig . Sensor Controller Hardware Design]]

When using multiple MaxSonar sensors, it is required to configure the sensors in ''Sequential Operation'' mode to obtain the best optimal performance in obstacle detection. On the other hand, if the sensors are left in continuous free run operation, which means the RX pin (Pin 4) are unconnected then at start-up the sensors will range at exactly the same time. Thus, the sensors are not synchronized and eventually result in frequency drifts that would likely cause interference between sensors for most applications.

[[File:CmpE243_F14_T5_SingleSensor.jpg|500px|thumb| center |Fig . Single Sensor in free run operation mode - MaxBotix 2012]]

The figure to the above shows a single MaxSonar ultrasonic sensor operating in continuous free run operation detecting an object at 96 inches. The signal of the ultrasonic sensor observe under the oscilloscope shows that the sensor is operating at its finesse performance without any interference.

The figure to the below shows that multiple MaxSonar ultrasonic sensors are operating in continuous free run operation. As you can see, the signal of a ultrasonic sensor observe under the oscilloscope shows that the signal has multiple spikes due to the interference of other sensors. Thus, the sensor becomes unsynchronized and the range reading become unstable.

[[File:CmpE243_F14_T5_MultipleSensorsInterferences.jpg‎|500px|thumb| center |Fig . Multiple Sensors in free run operation mode - MaxBotix 2012]]

To achieve the most optimal performance using multiple MaxSonar ultrasonic sensors, the figure below shows the implementation of all the sensors operating in sequential mode. The sensors can be started by pulling the RX pin (Pin 4) high for at least 20 uS and then for each reading this can be done as often as every 50 ms. This method would toggle each sensor when the user like to obtain an reading at any given moment. Thus, there will be no interference between each sensor.

[[File:CmpE243_F14_T5_MultipleSensorsConfiguration.jpg‎ |500px|thumb| center |Fig . Multiple Sensors Configuration]]

There are many other method to implement multiple MaxSonar ultrasonic sensors in a single system. This information can be obtained in the sensor datasheet.

===Sensor Controller Software Design===

== Central Controller ==

The central controller is the brain of the car. It receives information from all the other controllers and decides which direction the car must move. The central controller periodically sends commands to the motor regarding the throttle, steering, steering angle and speed.

In order to decide which direction to move, the central controller uses sensor data and geographical data. The current design uses a state machine. The car is initially in idle state. When it received a START command from the communication controller, the central sends the start motor command to the motor controller. After the start state, the central controller can be in one of the two states: avoid obstacle or adjust heading. The central controller uses the sensor data to detect obstacle. If there are no obstacles, then the central controller uses geographical information to adjust car heading.

Once the heading and bearing match, the car moves straight ahead till the destination is reached. When the geographical controller sends a command indicating that the car has reached the destination, the car will stop.

At any point during its course, if the car receives a STOP command from the communication controller, the car will stop

[[File:Cmpe243F14_Team5_Central_StateTransition.JPG|700px|thumb|center|Fig. Central Controller State Diagram]]

== Geographical Controller ==

The geographical controller is one of the six controllers mounted on the car. This controller provides the location and heading information to the central controller of the car. It also stores the destination (way-points). By calculating the distance from the current location to the destination or intermediate waypoint, the geo controller can determine if the car has reached its destination. When the car reaches the destination, the geo controller sends a message to the central controller indicating that destination has been reached.

The devices connected to this controller are:
1. Magnetometer (digital compass)
2. GPS Logger

The compass communicates via I2C and the GPS via UART.

==== Parts Used ====
{| class="wikitable"
|+ Geographical Control - Parts Used
|-
! align="center"|Part Number
! align="center"|Purpose
|-
| SparkFun Triple Axis Magnetometer Breakout - HMC5883L
| Compass
|-
| SparkFun Venus GPS Logger - SMA Connector
| GPS
|-
| Antenna GPS Embedded SMA - GPS-00177
| Antenna
|-
| ET-318 GPS Engine Board
| GPS
|}

==== Design ====

'''Heading''' - The compass provides the heading. The heading is the direction in which the car is headed. The value is typically an angle from 0-360 degrees measured clockwise from North. The heading is calculated from the x-axis and y-axis values provided by the magnetometer. To use all 3-axis values, a tilt sensor must be used with the magnetometer for tilt compensation.

'''GPS Module''' - The GPS module provides the time, latitude, longitude, direction and if the GPS data is valid. This latitude, longitude corresponds to the current location of the car.

'''Destination''' - The destination is set by Android application/communication controller. The destination could be a single point or a list of waypoints, each being a latitude, longitude pair.

'''Bearing''' - Using the destination lat,lon pair (set by the communication controller) and the current lat, lon pair (received from the GPS module), the geographical controller calculates the bearing. This angle, like the heading, is also typically between 0-360 degrees measured clockwise. Bearing represents the angle between the destination and current location.

Both the heading and the bearing are sent periodically to the central controller. The central controller uses this information combined with the sensor data to steer the motors in the right direction.

Example: If the current heading is 10 degrees ( car is travelling in a direction 10 degrees) from north. The bearing is 50 degrees ( the car is at an angle of 50 degrees away from the desired direction), the central controller must steer the car 40 degrees to the right.

The geographical controller also calculates the distance between the current lat, lon and the destination lat, lon. This is used to determine if the car has reached the intended destination. When the car has reached the destination, geographical controller sends a message to the central controller to stop.

==== Tasks ====
{| class="wikitable"
|+ Geographical Control - Tasks
|-
! align="center"|Task Name
! align="center"|Purpose
|-
| Compass Task
| Updates the compass heading. Runs every 100ms and obtains compass data over I2C
|-
| GPS Task
| Updates the current latitude and longitude by reading GPS data sent over UART. GPS has been configured to run at 10Hz and sends data at a baud rate of 38400.
|-
| CAN Rx Task
| Handles data received over CAN. Task gets blocked if can receive queue is empty.
|-
| CAN Periodic Msg Task
[1 Hz]
| Periodic CAN message to send current lat,lon and destination lat, lon to central and display controller
|-
| CAN Periodic Msg Task
[20 Hz]
| Periodic CAN message to send compass heading and destination bearing to central controller.
|}

==== GEO CAN Controller Communication Table ====
{| class="wikitable"
|+ Geographical Controller Communication Table
|-
! scope="col"| Message Number
! scope="col"| Message Type
! scope="col"| Purpose
! scope="col"| Data layout
|-
| 0x0301
| Get Geo Data
| Request for GPS Data (lat,long)
|
|-
| 0x0302
| "
| Request for current compass heading and destination heading
|
|-
| 0x0304
| "
| Request Time
|
|-
| 0x0601
| Response to 0x3xx request
| GPS Data (lat,long)
|
dword[0] : [32-bit latitude]
dword[1] : [32-bit longitude]
|-
| 0x0602
| "
| Compass heading and destination bearing
|
dword[0] : [32-bit compass heading]
dword[1] : [32-bit destination bearing]
|-
| 0x0504
| "
| Time
|
dword[0] : [32-bit time 0x00hhmmss]
|-
| 0x0501
| Periodic Message
| GPS data, broadcast periodically
|
dword[0] : [32-bit longitude]
dword[1] : [32-bit latitude]
|-
| 0x0502
| "
| Current and destination heading broadcast periodically
|
dword[0] : [32-bit compass heading]
dword[1] : [32-bit bearing]
|-

|}

==== Challenges and Lessons Learnt ====

# '''Start Geo work early''' : Most of the tasks of the geo controller can be done independent of the progress on the rest of the car. Start working early, test the GPS outside as much as possible.
# '''Compass calibration''' : Most compasses need calibration. During the course of our project, we used to magnetometers (since we accidently burned the first one). The first one was off by 5 degrees and the second one was off by about 20 degrees. Take care that the compass is mounted away from motors and other devices that can create a lot of noise for the compass
# '''GPS speed''' : We started by using the default speed of 1Hz on the GPS module. The data was sent to the central controller at 1 Hz. As we started testing we realized that this can be too slow and the car may go off course before the new data arrives. Using the commands in the datasheet, we configured the GPS to have an update rate of 10 Hz and a baud rate of 38400. While the datasheet said that the GPS can be configured for 20Hz and baud rate of 115200, we were unsuccessful in achieving that. For some reason, the SJOne board crashed every time we set the GPS for 115200. We did not successfully debug the issue. But changing the speed from 1Hz to 10Hz did make a lot of difference to the performance of the car steering.
# '''Picking the right GPS and compass''' : Both the compass and the GPS that we used served the purpose well. On sunny days, the GPS worked indoors too. Even though we used a 3 axis compass, we used only 2 axis readings from it to calculate the heading. A 3 axis compass paired with a tilt sensor would probably give better readings. But 2 axis readings served our purpose.
# '''GPS Drift''' : We noticed that the GPS values for the same locations drifted over time. There could be a 6 foot jump every few hours. The datasheet offers configurations to pin or unpin the gps values. We did not use the feature. But we did notice that because of the GPS drift, our car traveled differently on the same path at different times during the day. If we had more time, we could have fixed this and achieved a straight path for the car, instead of always veering to the left of right.
# '''Android App''' : The Android app is crucial since it provides the destination waypoints to the geo controller. We need to ensure that the dataset used by the android app is similar if not same as the values reported by the GPS. If the values differ a lot, then the car will not move along the intended path. The Android team and the GPS team must work closely and complete their testing well ahead, so that once the GPS and communication controllers are mounted it is only a matter of improving the behavior.
# '''Multiple Setups''' : Having multiple setups can be very helpful to debug issues, since it is easier to make changes on the temporary setup than on the car. Also, considering the size of the team, different teams might be using the car and the GPS team will always be the last team to get hold of the car.

==== Review of Parts used ====
The parts used for this controller were good and I would use them again.

== IO Controller ==

=== Summary ===

The IO controller's purpose is to display useful information on an LCD screen for debugging and verification purposes. Essentially, it monitors the CAN bus for other controllers' data as well as bus utilization. The hardware and software design is described below, as well as the challenges we encountered along the way.

=== Hardware Design ===

The hardware design of the IO controller is relatively simple. The only requirements are the serial LCD module and the controller itself. The LCD interfaces to the IO controller via UART protocol, while the IO controller interfaces to tater other controllers via CAN Protocol. The [[F14: Team5-Self Driving Car - AUG#Design & Implementation|block diagram]] above shows gives a clear description of the IO controller's place in the system.

The LCD chosen was a serial enabled 20x4 character display from [https://www.sparkfun.com/products/9568 Sparkfun]. It was chosen for it's larger character display (rather than 16x2) and because the serial "backpack was built into the PCB. This backpack is used because the display controller communicates with a parallel interface. The serial "backpack" or converter interfaces the parallel connections with a serial one and provides a low level API to control the display. An additional API was designed on top of this one to make programming simple and clear as well as implement some useful features (such as printing with printf style arguments). It operates on 5V, so it could not be powered by the controller itself and need to use one of the 5V supplies on the car.

=== Software Design ===

==== RX Task ====

The receiving task uses the interrupt driven CAN driver to process messages sent on the bus. When a CAN message is received, the data is filtered and stored a global memory locations. This data is later used by the IO task to format and print the desired information to the LCD. No hardware filter was used, since the IO controller must monitor bus utilization and therefore listen to all messages. No heavy calculations or blocking code is allowed in this task; it's purpose is to get the data out as fast as possible and wait for more.

==== LCD API ====

The LCD API uses a singleton template so that any task can invoke it and print something to the LCD. Since the LCD doesn't care who prints what, care must be taken to ensure other tasks' data isn't unintentionally overwritten. However, only a single task in our implementation is utilizing this API so it wasn't a problem. The LCD communicates over UART, so the available UART driver was used (also a singleton template). The data sheet from Sparkfun was used to create this API so that nearly all the LCD capabilities can be supported. These features include:

* Erase screen or individual line
* Write to screen, line or specific location
* Adjust backlight brightness
* Adjust cursor position and style
* Scroll text
* Turn display off or on
* Change baud rate

==== IO Task ====

[[File:CmpE243_F14_T5_LCDScreenDesign.png|700px|thumb|center|Fig. LCD screen object design]]

The IO task utilizes the LCD API to display LCD "screens". A screen is a custom-defined object containing "line" objects. Lines consist of a format sting (in the printf format) and optional variables. All screens are stored in a vector, of which the front object is always displayed on the LCD. To change the screen, the vector is simply rotated left or right (forward or backward). For simplicity, the screens are rotated every second. However the screens can be rotated by button press, timer, external interrupt or even CAN message.

The data objects that are stored in shared memory by the RX task make up the variables in the format strings described above. To accomplish this, the data types for these variables are char**, or a pointer to a char pointer. That way, we can just supply the memory location of the char* that is constantly being updated by the RX task. This simplifies the implementation of the IO Task and ensures the latest data is used when printing the screens.

[[File:CmpE243_F14_T5_IOTaskFlowChart.png|700px|thumb|center|Fig. IO task flow chart]]

== Controller Communication Table ==

{| class="wikitable"
|+ Controller ID Table
|-
! width="30" align="center"|Controller ID
! width="350" align="center"|Controller
|-
| 0x01
| Master Controller
|-
| 0x02
| Geographical Controller
|-
| 0x03
| Motor Controller
|-
| 0x04
| Sensor Controller
|-
| 0x05
| IO Controller
|-
| 0x06
| Communication (Bluetooth Bridge/Android App) Controller
|}

{| class="wikitable"
|+ Central Controller Communication Table
|-
! scope="col"| Sl. No
! scope="col"| Message Number
! scope="col"| Purpose
! scope="col"| Data layout
|-
! scope="row"|1
| 0x501
| Send Throttle and steering to motor
| throttle
steering
|-
! scope="row"| 2
| 0x502
| Start car
|
|-
! scope="row"| 3
| 0x503
| Stop car
|
|-
! scope="row"| 4
| 0x101
| Broadcast request revision
|
|-
! scope="row"| 5
| 0x102
| Broadcast Set time
|
|-
! scope="row"| 6
| 0x103
| Request TX count (broadcast)
|
|-
! scope="row"| 7
| 0x104
| Request RX count (broadcast)
|
|-
! scope="row"| 8
| 0x105
| Send TX count (LCD)
|
|-
! scope="row"| 9
| 0x106
| Send RX count (LCD)
|
|-
! scope="row"| 10
| 0x107
| All controllers initialize
|
|-
|}

{| class="wikitable"
|+ Communication (Bluetooth Bridge/Android App) Controller Communication Table
|-
! scope="col"| Sl. No
! scope="col"| Message Number
! scope="col"| Purpose
! scope="col"| Data layout
|-
! scope="row"|1
| 0x301
| Broadcast Start command
|
|-
! scope="row"| 2
| 0x302
| Broadcast Stop command
|
|-
! scope="row"| 3
| 0x303
| Broadcast GPS destination set by Android
|byte [0-3] : (float), Longitude
byte [4-7] : (float), Latitude
|-
|}

{| class="wikitable"
|+ Sensor Controller Communication Table
|-
! scope="col"| Sl. No
! scope="col"| Message Number
! scope="col"| Purpose
! scope="col"| Data layout
|-
! scope="row"|1
| 0x501
| Broadcast front sensors values
| byte[0]: Right ultrasonic sensor value in inches
byte[1]: Front ultrasonic sensor value in inches

byte[2]: Left ultrasonic sensor value in inches

byte[3]: Front bottom infrared sensor value in inches
|-
! scope="row"| 2
| 0x502
| Broadcast back infrared sensor value
| byte[0]: Back infrared sensor value in inches
|-
! scope="row"| 3
| 0x503
| Broadcast battery sensor value
|byte[0]: current/voltage sensor value in percentage
|-
! scope="row"| 4
| 0x504
| Broadcast light sensor value
|byte[0]: light sensor value as integer
|-
! scope="row"| 5
| 0x505
| Broadcast tilt sensor value
|byte[0]: X-Axis tilt sensor value as integer
byte[1]: Y-Axis tilt sensor value as integer

byte[2]: Z-Axis tilt sensor value as integer
|-
|}

{| class="wikitable"
|+ Motor/Servo Controller Communication Table
|-
! scope="col"| Sl. No
! scope="col"| Send Code
! scope="col"| Description
! scope="col"| Data
|-
! scope="row"|1
| 0x201
| Heartbeat data
| Controller id 1 byte
|-
! scope="row"| 2
| 0x201
| Heartbeat data
| Controller id 1 byte
|-
! scope="row"| 3
| 0x201
| Heartbeat data
| Controller id 1 byte
|-
! scope="row"| 4
| 0x202
| Mem info data
| Sys-mem remaining 4bytes
|-
! scope="row"| 5
| 0x501
| RPM data send
| RPM (2 bytes)
|-
! scope="row"| 6
| 0x502
| Speed data send
| Speed (2bytes)
|-
! scope="col"| Sl. No
! scope="col"| Receive Code
! scope="col"| Description
! scope="col"| Response
|-
! scope="row"| 1
| 0x300
| Kill
| Receive only
|-
! scope="row"| 2
| 0x301
| Stop
| Receive only
|-
! scope="row"| 3
| 0x302
| Straight
| Receive only
|-
! scope="row"| 4
| 0x307
| move forward 25%
| Receive only
|-
! scope="row"| 5
| 0x30C
| move forward 50%
| Receive only
|-
! scope="row"| 6
| 0x311
| move forward 75%
| Receive only
|-
! scope="row"| 7
| 0x315
| move forward 100%
| Receive only
|-
! scope="row"| 8
| 0x31A
| move backward 25%
| Receive only
|-
! scope="row"| 9
| 0x31F
| move backward 50%
| Receive only
|-
! scope="row"| 10
| 0x324
| move backward 75%
| Receive only
|-
! scope="row"| 11
| 0x329
| move backward 100%
| Receive only
|-
! scope="row"| 12
| 0x334
| Steer right 25%
| Receive only
|-
! scope="row"| 13
| 0x339
| Steer right 50%
| Receive only
|-
! scope="row"| 14
| 0x33E
| Steer right 75%
| Receive only
|-
! scope="row"| 15
| 0x343
| Steer right 100%
| Receive only
|-
! scope="row"| 16
| 0x348
| Steer Left 25%
| Receive only
|-
! scope="row"| 17
| 0x34D
| Steer left 50%
| Receive only
|-
! scope="row"| 18
| 0x352
| Steer left 75%
| Receive only
|-
! scope="row"| 19
| 0x357
| Steer left 100%
| Receive only
|-
|}

{| class="wikitable"
|+ Io Controller Communication Table
|-
! scope="col"| Sl. No
! scope="col"| Message Number
! scope="col"| Purpose
! scope="col"| Destination
|-
! scope="row"|1
| 0x301
| Start command for car
| Central Controller
|-
! scope="row"| 2
| 0x302
| Stop command for car
| Central Controller
|-
! scope="row"| 3
| 0x303
| Go to a predefined Destination.
| Central Controller
|}

== Testing & Technical Challenges ==
=== Sensors ===
The first challenge was the positioning and spacing between the sensors. The sensors were mounted on a 3D printed bracket for initial testing but the angle between the brackets seemed to cause interference and was not giving optimum values. The sensors were then individually mounted further apart to reduce interference. The detection distance was tweaked by trial and error and finally settled on the value of 36 inches for the front, left and right sensors and 7 inches for the back sensor.

The second challenge was dealing with erroneous values. Using ADC to interface sensors lead to certain erroneous values that didn't have the desired effect and after some testing, the sensor interface was changed to pulse width. This lead to more robust values after filtering.

Another challenge was the initial skewed alignment. It was difficult to detect whether the direction of the running car was changing because of the motor response to sensor values or the alignment of the tires. The group eventually decided to get a new car that rectified the alignment issue.

=== Sensors Configuration and Implementation ===
We used LV-MaxSonar series MB1010 high performance ultrasonic sensors for our application. The sensors detects objects from 6 inch to 254 inches and can be interfaced to ADC or pulse width output. We found the ADC values were inconsistent and due to the constraint of number of ADC pins on SJONE board , we used PWM to configure the sensors.
We mounted three sensors in front of the car and we found the values were not consistent as it was reflected from the ground, hence we elevated the sensor placement.
The sensor configuration is explained
[[File:CMPE243_F14_Group5_ultrasonic.png|200px|centre|thumb|Ultra SonicSensor]]

===Motor Controller ===

====Issue 1====
As we were using Electric Speed Control (ESC) to control the speed of motor we faced issues based on inconsistency of the speed. This could have been solved easily if we used H-bridge chip. When ESC was supplied with particular PWM signal it would work at desirable speed but when turning off the ESC and turning on the ESC the speed would change for the same PWM signal supplied. This inconsistency of the speed can easily damaged the motor as it was hard to predict when the motor will switch from forward to backward motion. So to fix this issue we had to connect the ESC to oscilloscope and turn on the transmitter. As soon as the transmitter is turned on the transmitter send a fix signal to ESC for some time that could have been in milli seconds. By doing this the ESC get initialized and once the ESC has initialized the transmitter can send a signal to go forward or reverse.

So we wrote a code to initialize the ESC. Before we sends the signal to ESC to move forward or reverse we send a fix PWM signal to ESC for one second to initialize ESC and this signal was sent from the main function.

====Issue 2====
The servo that came with the RC car wasn't fast enough to respond to left and right movement of the car. Car would hit the obstacle and than the wheel would rotate in opposite direction. So we change the servo with faster response time.

{| class="wikitable"
|-
! scope="col"|Sl. No
! scope="col"|Test Case
! scope="col"|Test Description
! scope="col"|Result
|-
| scope="row"|1||Initial CAN communication of all controllers ||Check if all the controllers are broadcasting the periodic message on CAN bus and receiving the data ||All controllers '''PASSED'''
|-
| scope="row"|2||Obstacle avoidance|| Obstacle by integrating the ultrasonic sensor||Obstacle avoidance '''PASSED'''
|-
| scope="row"|3||LCD display || Displying all the values including CPU Utilization, CAN message count, and message from the controllers ||LCD display of all message '''PASSED'''
|-
| scope="row"|4||Building Android application ||Check if the Android application sends the destination by Bluetooth||Communication '''PASSED'''
|-
| scope="row"|5||Point to Point movement || Test Car runs by setting two way points||Point to point car movement '''PASSED'''
|-
| scope="row"|6||Checking if Car runs with multiple way points ||Check if the car works with multiple way points||Multiple way points steering '''PASSED'''
|-
|}

== Challenges and Learning ==

== Future Enhancement ==
=== Sensors ===
It would be ideal to add another infrared sensor to the front lower portion of the car for cliff detection. It would also be good to have a bigger 3D printed bracket to mount the sensors that match our measurements requirements. This would add to the visual appeal and also reduce tangling mess due to the wires.

== Conclusion ==

== Project Video ==

Demo : http://youtu.be/a9ceLDJN67M

Teampics : http://youtu.be/TJW7AsHpXfE

== Project Source Code ==

== References ==
=== Acknowledgement ===

=== References Used ===
# Preetpal Kang, Lecture notes of CMPE 243, Computer Engineering, Charles W. Davidson College of Engineering, San Jose State University, Aug-Dec 2014.
# en.wikipedia.org/
# MaxBotix 2012, http://www.maxbotix.com/articles/031.htm

File:CmpE243 F14 T5 IOTaskFlowChart.png

2014-12-23T03:48:58Z

146S12T4:

F14: Team5-Self Driving Car - AUG

2014-12-23T03:39:00Z

146S12T4: /* RX Task */

== Self Driving Car ==

== Objective and Scope ==

This project is aimed at creating a self-driving car with obstacles avoidance and to steer to the gps location pointed by the android application with the help of multiple controllers communicating using CAN bus.CAN(Control Area Network) is a communication protocol used widely in automotive application developed by BOSCH in 1986. The self-driving car consists of 6 different controllers for '''GPS''','''Sensor''','''Central''','''Motor''','''IO''' and '''Communication'''. The controllers communicate to other controller by CAN bus.We have implemented broadcast algorithm to broadcast all the data from each controller in different frequencies. The controller parses the data using the 29 bit identifier which has destination and source address.

[[File:CmpE244_F14_SelfDrivingCarT5_basic_can_updated.JPG|700px|thumb|center|Fig 2. Build in Progress]]
[[/File:CmpE244_S14_Quadcopter_Propeller_direction2.JPG|400px|thumb|right|Fig 2. Propeller rotating direction]]

== Team Members & Responsibilities ==

{| class="wikitable"
|-
! scope="col"| Sl. No
! scope="col"| Task
! scope="col"| Team Members
|-
! scope="row"| 1
| Sensor Controller
|
# Bailey Wu
# Rishabh Sareen
# Rishab H
|-
! scope="row"| 2
| Motor Controller
|
# Abhraham Ruiz
# Arpit Amin
# Sree Harsha
|-
! scope="row"| 3
| I/O Controller (LCD Display)
|
# Yoni Klein
# Tejeswar
|-
! scope="row"| 4
| Communication Bridge + Android
|
# Shaw Ken Chang
# Arnold Bajet Jr.
# Thomas Pantels
|-
! scope="row"| 5
| Geographical Controller
|
# Himanshu Saini
# Divya Kamath
|-
! scope="row"| 6
| Central Controller
|
# Divya Kamath
# Tejeswar
# Sree Harsha
|-
! scope="row"| 7
| Car design and wiring
|
# Bailey Wu
# Himanshu Saini
# Sree Harsha
# Karthik Vadiraja
# Akash Ayare
|-
! scope="row"| 8
| Git Setup
| Akash Ayare
|-
|}

== Introduction ==

The goal of this project was to design and implement a self-driving car. The team consisted of 15 people, divided into 6 teams corresponding to six controllers. The aim of this class was to understand the CAN protocol that is used extensively in vehicles. The self-driving car houses six controllers, all of them communicating using CAN. Each controller performs a unique task such as:
# '''Sensor Controller''': Interfaced to the front and back sensors. Periodically sends sensor data to the central controller. Crucial for obstacle detection and avoidance
# '''Motor Controller''': Controls the motors and steering of the car, based on commands received from central controller.
# '''Geographical Controller''': Interfaced to GPS and compass. Periodically sends location, heading and distance from destination. crucial for autonomous navigation of the car.
# '''Communication Controller''': Acts as a bridge for Android. Android app is used to set destination, calculate path to destination, start and stop the car. Data is sent to central and geographical Controller based on user input.
# '''Central Controller''': The brain of the car. Uses sensor and geographical data to steer the car in the right direction. Uses sensor data to detect and avoid obstacles. Uses geographical data to move towards desired location
# '''Display Controller''': Interfaced to an LCD screen which displays status of the car (reached/ not reached), CAN bus utilization, sensor data, bearing, heading etc.

== Schedule ==

'''Geographical Controller'''

{| class="wikitable"
|-
! scope="col"| Sl. No
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Actual Completion Date
|-
! scope="row"| 1
| 1-Oct-2014
| 14-Oct-2014
| Order Components and Make a schedule
| Completed
| 14-Oct-2014
|-
! scope="row"| 2
| 8-Oct-2014
| 14-Oct-2014
| Decide commands that Geographical Controller will support
| Completed
| 14-Oct-2014
|-
! scope="row"| 3
| 7-Oct-2014
| 14-Oct-2014
| Complete CAN RX task and subscription handling. Verify communication with other controllers
| Completed
| 21-Oct-2014
|-
! scope="row"| 4
| 14-Oct-2014
| 24-Oct-2014
| Interface GPS module and Compass and develop drivers if needed
| Completed
| 28-Oct-2014
|-
! scope="row"| 5
| 24-Oct-2014
| 30-Oct-2014
| Design and develop algorithm to calculate heading and bearing from GPS coordinates
| Completed.
| 30-Oct-2014
|-
! scope="row"| 6
| 24-Oct-2014
| 5-Nov-2014
| Work on calibration of compass and heading calculation
| Completed
| 11-Dec-2014
|-
! scope="row"| 7
| 1-Nov-2014
| 10-Nov-2014
| Test with the central and Bluetooth controller
| Completed
| 14-Dec-2014
|-
! scope="row"| 8
| 10-Nov-2014
| 25-Nov-2014
| Begin testing with fully assembled car
| Completed
| 1-Dec-2014
|-
|-
! scope="row"| 9
| 25-Nov-2014
| 10-Dec-2014
| Final Testing and changes as needed
| Completed
| 19-Dec-2014
|-
|}

'''Sensor Controller'''

{| class="wikitable"
|-
! scope="col"| Sl. No
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Actual Completion Date
|-
! scope="row"| 1
|10/3/2014
|10/10/2014
|Order ultrasonic sensor parts and develop simple test code for the sensors
|Done
|10/10/2014
|-
! scope="row"| 2
|10/10/2014
|10/17/2014
|Wire the ultrasonic sensors, develop and implement the sensors using analog to digital converter
|Done
|10/17/2014
|-
! scope="row"| 3
|10/17/2014
|10/24/2014
|Collaborate with the other sub teams to finish the CAN bus communication and allow the self driving car to drive autonomously
|Done
|10/24/2014
|-
|! scope="row"| 4
|10/24/2014
|11/1/2014
|Develop, implement and test the ultrasonic sensors using the pulse width modulation and universal asynchronous receiver/transmitter
|Done
|11/1/2014
|-
! scope="row"| 5
|11/2/2014
|11/9/2014
|Develop, implement and test the front and back infrared sensors using analog to digital converter
|Done
|11/9/2014
|-
! scope="row"| 6
|11/10/2014
|11/17/2014
|Develop, implement and test the current/voltage sensor for the battery packs of the self driving car using I2C
|Scheduled
|Removed
|-
! scope="row"| 7
|11/18/2014
|11/25/2014
|Collaborate with the other sub teams to make sure that the sensors are in working condition
|Done
|11/25/2014
|-
|-
! scope="row"| 8
|11/26/2014
|12/5/2014
|Collaborate with the other sub teams to debug any problems that may encountered
|Done
|12/5/2014
|-
! scope="row"| 9
|12/6/2014
|12/13/2014
|Prepare for demo
|Done
|12/19/2014
|-
|}

'''IO Controller'''

{| class="wikitable"
|-
! scope="col"| Sl. No
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Actual Completion Date
|-
|-
! scope="row"| 1
|10/7/2014
|10/14/2014
|Research and order LCD appropriate for this project
|Done
|10/11/2014
|-
|-
! scope="row"| 2
|10/7/2014
|10/17/2014
|Implement CAN RX/Subscription task
|Done
|10/13/2014
|-
|-
! scope="row"| 3
|10/7/2014
|10/17/2014
|Finalize Task Architecture
|Done
|11/1/2014
|-
|-
! scope="row"| 4
|10/18/2014
|10/21/2014
|Interface and test LCD
|Done
|10/20/2014
|-
|-
! scope="row"| 6
|10/21/2014
|10/28/2014
|Implement auto scrolling feature
|Done
|11/18/2014
|-
|}

'''Communication Bridge + Android'''

{| class="wikitable"
|-
! scope="col"| Sl. No
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Actual Completion Date
|-
! scope="row"| 1
| 16-Sep-2014
| 23-Sep-2014
| Test bluetooth module using computer serial port and an android app(simple bluetooth terminal app downloaded from google play). Test the real life range and stability of the bluetooth module (HC-06). Modify the bluetooth chat example to work with the bluetooth module.
| Done
| 20-Sep-2014
|-
! scope="row"| 2
| 28-Sep-2014
| 12-Oct-2014
| Draw UI design layouts for a basic android application that can view Google map as well as send GPS data through bluetooth by clicking on the map. Study google maps API and make a simple app that will post a short toast that shows the GPS location after a long press event.
| Done
| 12-Oct-2014
|-
! scope="row"| 3
| 7-Oct-2014
| 11-Oct-2014
| Interface bluetooth module with SJSUOne board and able to verify that the connection is stable and that transaction via the bluetooth is accurate. This is done by adding a test button where if you press the button it send a command to the board. After receiving the command, the board should react with a response (LED light and/or text response to the android phone)
| Done
| 19-Oct-2014
|-
! scope="row"| 4
| 11-Oct-2014
| 19-Oct-2014
|Integrate Google Maps and Bluetooth component together in Android app. After a long press on the map, the user should be prompted to start the car and set the location as the places the user selected. Add a textView to display the location selected by pressing on the map. Add a button for sending location to the car.
| Done
| 27-Oct-2014
|-
! scope="row"| 5
| 19-Oct-2014
| 26-Oct-2014
| CAN infrastructure implmentation: Use our team's common CAN infrasturcture code and modify it specifically for our controller. First created the CAN communication table and then modify the infracturacture code to implement the broacasting as well as filtering of neccessary data. This only focuses on broadcasting a stop/start command and the destination GPS data (set by android) as well as getting car's current location data from the geological controller.
|Done
| 07-Nov-2014
|-
! scope="row"| 6
| 26-Oct-2014
| 1-Nov-2014
| Test and implement car information reading as well as other functions of Android app
| In Progress
|
|-
! scope="row"| 7
| 2-Nov-2014
| 4-Nov-2014
| Iterate UI design
| In Progress
|
|-
! scope="row"| 8
| 5-Nov-2014
| 16-Nov-2014
| Implement 2nd UI design
| In Progress
|
|-
|}

'''Motor Controller'''

{| class="wikitable"
|-
! scope="col"| Sl. No
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Actual Completion Date
|-
|-
! scope="row"| 1
|10/1/2014
|10/8/2014
|PWM2 (used to control motors) and PWM3 (used to control servo) interface with the car servo and motor. Write a test code to operate the servo and motor from the terminal command.
|Completed and Tested
|10/11/2014
|-
|-
! scope="row"| 2
|10/9/2014
|10/18/2014
|Design and code CAN receive task for subscription. Check for basic CAN message commands for throttle and steer control.
|Completed and tested
|10/26/2014
|-
|-
! scope="row"| 3
|10/19/2014
|10/28/2014
|Design the CAN message table for motor control and servo control
|Completed and tested
|10/26/2014
|-
|-
! scope="row"| 4
|10/29/2014
|11/07/2014
|Design acceleration Vs steer control function for smooth run. Check for other factors involved.
|Completed and tested
|11/22/2014
|-
|-
! scope="row"| 5
|11/08/2014
|11/14/2014
|Research on RPM sensor. Interface the RPM sensor to calculate the Speed. Test the RPM sensor by running the car at different speed
|Completed and tested with a hall sensor
|11/22/2014
|-
|-
! scope="row"| 6
|11/15/2014
|11/21/2014
|Fine tune motor control code and integrate with all the controllers for proper working.
|Completed and tested
|11/22/2014
|-
|-
! scope="row"| 7
|11/22/2014
|11/28/2014
|Test and check if more features can be added to improve performance. Completed and tested
|Completed and tested
|11/28/2014
|-
|-
! scope="row"| 8
|11/29/2014
|12/05/2014
|Testing and Debugging.
|Completed and tested
|12/05/2014
|-
|-
!scope="row"|9
|12/06/2014
|12/18/2014
|Final Testing and getting the car ready for Demo.
|On Going
|

|}
'''Central Controller'''

{| class="wikitable"
|-
! scope="col"| Sl. No
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Actual Completion Date
|-
! scope="row"| 1
| 16-Sep-2014
| 23-Sep-2014
| Develop API for CAN bus communication.
| Done
| 23-Sep-2014
|-
! scope="row"| 2
| 11-Oct-2014
| 15-Oct-2014
| Develop communication table for all controllers.
| In Progress
|
|-
! scope="row"| 3
| 15-Oct-2014
| 20-Oct-2014
| Broadcast message and target message setup.
| Done
|
|-
! scope="row"| 4
| 21-Oct-2014
| 28-Oct-2014
| Co-ordinate all controllers and take major decisions.
| Done
|
|-
! scope="row"| 5
| 28-Oct-2014
| 11-Nov-2014
| Complete Building and fine-tuning of RC car.
| In Progress
|
|-
! scope="row"| 6
| 21-Oct-2014
| 11-Nov-2014
| Develop coordination mechanism to ensure controllers are initialized and ready
| In Progress
|
|-
! scope="row"| 7
| 21-Oct-2014
| 28-Oct-2014
| Develop kill switch
| Done
|
|-
! scope="row"| 8
| 14-Oct-2014
| 21-Oct-2014
| Build external power distribution circuit
| Done
| 21-Oct-2014
|-
! scope="row"| 9
| 28-Oct-2014
| 04-Nov-2014
| Coordination algorithm between steering and throttle for smooth turns
| In Progress
|
|-
! scope="row"| 10
| 04-Nov-2014
| 11-Nov-2014
| Collision avoidance algorithms
| Done
|
|-
! scope="row"| 11
| 04-Nov-2014
| 11-Nov-2014
| Intermediate unit and functional tests
| In Progress
|
|-
! scope="row"| 12
| 11-Nov-2014
| 25-Nov-2014
| Functional tests and algorithm adjustments
| In Progress
|
|-
! scope="row"| 13
| 25-Nov-2014
| 02-Dec-2014
| Fine tuning and stretch goals (headlights, parallel parking, etc.)
| Done
|
|-
! scope="row"| 14
| 02-Dec-2014
| 09-Dec-2014
| Prepare for demo
| In Progress
|
|-
|-

|}

== Parts List & Cost ==

{| class="wikitable"
! width="350" align="center"|Description
! width="30" align="center"|Qty
! width="60" align="center"|Price
|-
| LV-MaxSonar-EZ1 High Performance Ultrasonic Rangefinder
| 2
| 49.90
|-
| Analog Distance Sensor
| 1
| Free
|-
|1/10 Scale 4x4 Truck with Brushed Motor
|1
|217.33
|-
|2 ft 12-Gauge Power Cables
|3
|22.80
|-
|Pair Power Socket
|2
|2.16
|-
|Standard Size Body Clips
|12
|2.16
|-
|4-pack AA Batteries
|1
|3.45
|-
|50-pack M3x15mm Stand-Off Spacer Female-Male
|1
|11.19
|-
|100-pack 18-8 Flat Steel Washer
|1
|2.54
|-
|100-pack M3x20mm Hex-Drive Screw
|1
|6.47
|-
|100-pack M3 Steel Hex Nut
|1
|4.66
|-
|2-pin JST Connector Right Angle
|10
|6.84
|-
|4-pin JST Connector Right Angle
|10
|6.84
|-
|2-pin Female JST Cable (20 cm)
|10
|7.39
|-
|4-pin Female JST Cable (20 cm)
|10
|7.39
|-
|5 Volt Relay Breakout Board
|1
|4.95
|-
|5 Volt Voltage Regulator
|1
|1.07
|-
|Sharp Analog Distance Sensor 4-30 cm
|1
|9.95
|-
|3-pin Female JST PH-Style Cable (30 cm)
|1
|0.92
|-
|Double Sided Mounting Tape - 3 feet
|1
|4.35
|-
|AC Adapter (LiPo Charger)
|1
|15.16
|-
|IEC Power Cable (LiPo Charger)
|1
|5.38
|-
|4mm Bullet Plugs to Universal Plug
|1
|13.38
|-
|Acrylic sheet + Sharpe mini
|1+1
|11.72
|-
|Molex Pin Header, Connector, wires and 100 zip ties
|10+4+1
|17.13
|-
|2 x 90 degree pin header, 2 x straight pin header
|2+2
|3.65
|-
|uni-polar hall sensor for tachometer feedback
|2
|2.18
|-
|Heavy Duty magnets
|2
|4.18
|-
|INA219 Voltage sensors 26V +/-3.2A
|2
|19.9
|-
|-
|20x4 Serial LCD Module
|1
|29.99
|-
|}

== Backup Parts & cost ==

{| class="wikitable"
! width="30" align="center"|Qty
! width="350" align="center"|Description
! width="110" align="center"|Manufacturer
! width="60" align="center"|Part Number
! width="60" align="center"|Total Cost
|-
| 1
| LV-MaxSonar-EZ1 High Performance Ultrasonic Rangefinder
| MaxBotix Inc
| MB1010
| Free
|-
| 1
| Analog Distance Sensor
| Sharp
|
| Free
|-
|}

== Design & Implementation ==
[[File:CmpE243_F14_Team5_OverallHWDesign.jpg]]

== Motor Controller ==

==== Summary ====
This module takes command input from central controller and steers the car to its destination; in addition, It has two main controlling parameters : Throttle and Steering. Throttle input moves the car forward and backward. Steer input turns the wheel left and right. The central controller takes feedback from the sensors and makes decision to move the car. Accordingly, it sends CAN commands accepted by the motor controller for navigation, and real time RPM signal to the controller.

{| class="wikitable"
|+ Motor and Steer control : Technical Information
|-
! width="30" align="center"|Sl.No
! width="90" align="center"|Controller
! width="90" align="center"|Signal Type
! width="90" align="center"|Frequency
! width="350" align="center"|Functionality
|-
! scope="row"|1
| Motor Control
| PWM signal
| 50 Hz (20000us)
| 1000us (Full throttle forward) - 1500us (Stop) - 2000us (Full throttle backward)
|-
! scope="row"|2
| Steer Control
| PWM signal
| 50 Hz (20000us)
|1000us (Turn left max) - 1500us (Center) - 2000us (Turn right max)
|-
|}

===== Working =====
The car initially accepts the start command to begin navigation. Commands can then come to move the car forward or backward, steer left or right depending on intelligent decisions made by the central controller. The motor control has intelligence to avoid jerks and ensure smoother transitions between commands. The central controller gets the data from the sensors for obstacle avoidance. The car has a communication controller which gets the '''GPS''' data from the android application, the android application sets the destination latitude and longitude. The car decides the heading direction by the gps points and the compass and if it finds obstacle it will be controlled by the obstetrical avoidance and steer to the destination according to the algorithm below.
===== Flow Chart =====

[[File:Cmpe243_F14_T5_motor_controller_flowchart1.png]]

===== Kill switch =====
The remote control and receiver module pair up to provide a signal coverage of more than 100 meters. We make use of this to design our kill switch. When a constant PWM signal of 1000us is received from the remote, the car is in 'ARMED' state and moves the car according to CAN commands. The user has to hold the trigger gun for this state constantly and the car moves.
When the user releases the trigger gun, the car stops receiving the PWM signal of 1000us and the car goes to 'DISARMED' state.
In short, pull the trigger gun - ARMED, release the trigger gun - DISARMED.

===== RPM =====
The RPM sensor is based on a hall sensor switch which detect the North and South pole of a magnet located in the main shaft in the car. The hall sensor part number is 3177, and it has three pin. This sensor is uni-polar which give an output high signal when the sensor captures the North pole of the magnet; subsequently, the sensor give output low signal when the sensor captures the South pole of the magnet. Therefore, by using a the 3177 and a magnet in the shaft. the SJOne board can capture the output signal from the hall sensor as it toggles per shaft revolution.
It is important to notice that the output signal of the 3177 is an open collector; therefore, we need a 10 Kohm resistor connected to Vcc.

===== Pinout Table =====

The following table shows the pinout of all component that are connected to SJONE board.

{| class="wikitable"
|-
! scope="col"|No
! scope="col"|Description
! scope="col"|Component Pin
! scope="col"|Output Pin Source
|-
! scope="row"|1
|Hall Sensor (3177) Vcc ( 4.5 V to 18 V)
|Source
|SJOne P1_22
|-
! scope="row"|2
|Hall Sensor (3177) Ground
|Ground
|SJOne
|-
! scope="row"|3
|Hall Sensor (3177) Output
|Output
|SJOne P1_22 with a 10 KOhm
|-
!scope ="row"|4
|CAN Transceiver
|Pin # 1 TX
|SJOne P0_1(Tx)
|-
!scope ="row"|5
|CAN Transceiver
|Pin # 2 GND
|SJOne GND
|-
!scope ="row"|6
|CAN Transceiver
|Pin # 3 VCC
|SJOne 3.3v
|-
!scope ="row"|7
|CAN Transceiver
|Pin # 4 RX
|SJOne P0_0(Rx)
|-
!scope ="row"|8
|CAN Transceiver
|Pin # 6 CANL
|CAN Bus
|-
!scope ="row"|10
|CAN Transceiver
|Pin # 7 CANH
|CAN Bus
|-
!scope ="row"|11
|Servo
|VCC
|5V Power Rail
|-
!scope ="row"|12
|Servo
|GND
|GND Power Rail
|-
!scope ="row"|13
|Servo
|Signal
|PWM 2.1
|-
!scope ="row"|14
|Electric Speed Control (ESC)
|VCC
|5V Power rail
|-
!scope ="row"|15
|Electric Speed Control (ESC)
|GND
|GND Power Rail
|-
!scope ="row"|16
|Electric Speed Control (ESC)
|Signal
|PWM 2.2
|}

===== Block Diagram =====
The following Block diagram shows an overview of the connection between the SJOne board, ESC, and the Hall sensor:

[[File:Motor Block Diagram 1.jpg|600px|thumb|center|Motor Controller Block Diagram]]

== Sensor Controller ==
===Sensor Controller Hardware Design and Architecture ===

[[File:CmpE243_F14_T5_SensorHWDesign.jpg|700px|thumb| center |Fig . Sensor Controller Hardware Design]

When using multiple MaxSonar sensors, it is required to configure the sensors in ''Sequential Operation'' mode to obtain the best optimal performance in obstacle detection. On the other hand, if the sensors are left in continuous free run operation, which means the RX pin (Pin 4) are unconnected then at start-up the sensors will range at exactly the same time. Thus, the sensors are not synchronized and eventually result in frequency drifts that would likely cause interference between sensors for most applications.

[[File:CmpE243_F14_T5_SensorHWDesign.JPG|500px|thumb| center |Fig . Single Sensor in free run operation mode - MaxBotix 2012]]

The figure to the above shows a single MaxSonar ultrasonic sensor operating in continuous free run operation detecting an object at 96 inches. The signal of the ultrasonic sensor observe under the oscilloscope shows that the sensor is operating at its finesse performance without any interference.

The figure to the below shows that multiple MaxSonar ultrasonic sensors are operating in continuous free run operation. As you can see, the signal of a ultrasonic sensor observe under the oscilloscope shows that the signal has multiple spikes due to the interference of other sensors. Thus, the sensor becomes unsynchronized and the range reading become unstable.

[[File:CmpE243_F14_T5_MultipleSensorsInterferences.jpg‎|500px|thumb| center |Fig . Multiple Sensors in free run operation mode - MaxBotix 2012]]

To achieve the most optimal performance using multiple MaxSonar ultrasonic sensors, the figure below shows the implementation of all the sensors operating in sequential mode. The sensors can be started by pulling the RX pin (Pin 4) high for at least 20 uS and then for each reading this can be done as often as every 50 ms. This method would toggle each sensor when the user like to obtain an reading at any given moment. Thus, there will be no interference between each sensor.

[[File:CmpE243_F14_T5_MultipleSensorsConfiguration.jpg‎ |500px|thumb| center |Fig . Multiple Sensors Configuration]]

There are many other method to implement multiple MaxSonar ultrasonic sensors in a single system. This information can be obtained in the sensor datasheet.

===Sensor Controller Software Design===

== Central Controller ==

The central controller is the brain of the car. It receives information from all the other controllers and decides which direction the car must move. The central controller periodically sends commands to the motor regarding the throttle, steering, steering angle and speed.

In order to decide which direction to move, the central controller uses sensor data and geographical data. The current design uses a state machine. The car is initially in idle state. When it received a START command from the communication controller, the central sends the start motor command to the motor controller. After the start state, the central controller can be in one of the two states: avoid obstacle or adjust heading. The central controller uses the sensor data to detect obstacle. If there are no obstacles, then the central controller uses geographical information to adjust car heading.

Once the heading and bearing match, the car moves straight ahead till the destination is reached. When the geographical controller sends a command indicating that the car has reached the destination, the car will stop.

At any point during its course, if the car receives a STOP command from the communication controller, the car will stop

[[File:Cmpe243F14_Team5_Central_StateTransition.JPG|700px|thumb|center|Fig. Central Controller State Diagram]]

== Geographical Controller ==

The geographical controller is one of the six controllers mounted on the car. This controller provides the location and heading information to the central controller of the car. It also stores the destination (way-points). By calculating the distance from the current location to the destination or intermediate waypoint, the geo controller can determine if the car has reached its destination. When the car reaches the destination, the geo controller sends a message to the central controller indicating that destination has been reached.

The devices connected to this controller are:
1. Magnetometer (digital compass)
2. GPS Logger

The compass communicates via I2C and the GPS via UART.

==== Parts Used ====
{| class="wikitable"
|+ Geographical Control - Parts Used
|-
! align="center"|Part Number
! align="center"|Purpose
|-
| SparkFun Triple Axis Magnetometer Breakout - HMC5883L
| Compass
|-
| SparkFun Venus GPS Logger - SMA Connector
| GPS
|-
| Antenna GPS Embedded SMA - GPS-00177
| Antenna
|-
| ET-318 GPS Engine Board
| GPS
|}

==== Design ====

'''Heading''' - The compass provides the heading. The heading is the direction in which the car is headed. The value is typically an angle from 0-360 degrees measured clockwise from North. The heading is calculated from the x-axis and y-axis values provided by the magnetometer. To use all 3-axis values, a tilt sensor must be used with the magnetometer for tilt compensation.

'''GPS Module''' - The GPS module provides the time, latitude, longitude, direction and if the GPS data is valid. This latitude, longitude corresponds to the current location of the car.

'''Destination''' - The destination is set by Android application/communication controller. The destination could be a single point or a list of waypoints, each being a latitude, longitude pair.

'''Bearing''' - Using the destination lat,lon pair (set by the communication controller) and the current lat, lon pair (received from the GPS module), the geographical controller calculates the bearing. This angle, like the heading, is also typically between 0-360 degrees measured clockwise. Bearing represents the angle between the destination and current location.

Both the heading and the bearing are sent periodically to the central controller. The central controller uses this information combined with the sensor data to steer the motors in the right direction.

Example: If the current heading is 10 degrees ( car is travelling in a direction 10 degrees) from north. The bearing is 50 degrees ( the car is at an angle of 50 degrees away from the desired direction), the central controller must steer the car 40 degrees to the right.

The geographical controller also calculates the distance between the current lat, lon and the destination lat, lon. This is used to determine if the car has reached the intended destination. When the car has reached the destination, geographical controller sends a message to the central controller to stop.

==== Tasks ====
{| class="wikitable"
|+ Geographical Control - Tasks
|-
! align="center"|Task Name
! align="center"|Purpose
|-
| Compass Task
| Updates the compass heading. Runs every 100ms and obtains compass data over I2C
|-
| GPS Task
| Updates the current latitude and longitude by reading GPS data sent over UART. GPS has been configured to run at 10Hz and sends data at a baud rate of 38400.
|-
| CAN Rx Task
| Handles data received over CAN. Task gets blocked if can receive queue is empty.
|-
| CAN Periodic Msg Task
[1 Hz]
| Periodic CAN message to send current lat,lon and destination lat, lon to central and display controller
|-
| CAN Periodic Msg Task
[20 Hz]
| Periodic CAN message to send compass heading and destination bearing to central controller.
|}

==== GEO CAN Controller Communication Table ====
{| class="wikitable"
|+ Geographical Controller Communication Table
|-
! scope="col"| Message Number
! scope="col"| Message Type
! scope="col"| Purpose
! scope="col"| Data layout
|-
| 0x0301
| Get Geo Data
| Request for GPS Data (lat,long)
|
|-
| 0x0302
| "
| Request for current compass heading and destination heading
|
|-
| 0x0304
| "
| Request Time
|
|-
| 0x0601
| Response to 0x3xx request
| GPS Data (lat,long)
|
dword[0] : [32-bit latitude]
dword[1] : [32-bit longitude]
|-
| 0x0602
| "
| Compass heading and destination bearing
|
dword[0] : [32-bit compass heading]
dword[1] : [32-bit destination bearing]
|-
| 0x0504
| "
| Time
|
dword[0] : [32-bit time 0x00hhmmss]
|-
| 0x0501
| Periodic Message
| GPS data, broadcast periodically
|
dword[0] : [32-bit longitude]
dword[1] : [32-bit latitude]
|-
| 0x0502
| "
| Current and destination heading broadcast periodically
|
dword[0] : [32-bit compass heading]
dword[1] : [32-bit bearing]
|-

|}

==== Challenges and Lessons Learnt ====

# '''Start Geo work early''' : Most of the tasks of the geo controller can be done independent of the progress on the rest of the car. Start working early, test the GPS outside as much as possible.
# '''Compass calibration''' : Most compasses need calibration. During the course of our project, we used to magnetometers (since we accidently burned the first one). The first one was off by 5 degrees and the second one was off by about 20 degrees. Take care that the compass is mounted away from motors and other devices that can create a lot of noise for the compass
# '''GPS speed''' : We started by using the default speed of 1Hz on the GPS module. The data was sent to the central controller at 1 Hz. As we started testing we realized that this can be too slow and the car may go off course before the new data arrives. Using the commands in the datasheet, we configured the GPS to have an update rate of 10 Hz and a baud rate of 38400. While the datasheet said that the GPS can be configured for 20Hz and baud rate of 115200, we were unsuccessful in achieving that. For some reason, the SJOne board crashed every time we set the GPS for 115200. We did not successfully debug the issue. But changing the speed from 1Hz to 10Hz did make a lot of difference to the performance of the car steering.
# '''Picking the right GPS and compass''' : Both the compass and the GPS that we used served the purpose well. On sunny days, the GPS worked indoors too. Even though we used a 3 axis compass, we used only 2 axis readings from it to calculate the heading. A 3 axis compass paired with a tilt sensor would probably give better readings. But 2 axis readings served our purpose.
# '''GPS Drift''' : We noticed that the GPS values for the same locations drifted over time. There could be a 6 foot jump every few hours. The datasheet offers configurations to pin or unpin the gps values. We did not use the feature. But we did notice that because of the GPS drift, our car traveled differently on the same path at different times during the day. If we had more time, we could have fixed this and achieved a straight path for the car, instead of always veering to the left of right.
# '''Android App''' : The Android app is crucial since it provides the destination waypoints to the geo controller. We need to ensure that the dataset used by the android app is similar if not same as the values reported by the GPS. If the values differ a lot, then the car will not move along the intended path. The Android team and the GPS team must work closely and complete their testing well ahead, so that once the GPS and communication controllers are mounted it is only a matter of improving the behavior.
# '''Multiple Setups''' : Having multiple setups can be very helpful to debug issues, since it is easier to make changes on the temporary setup than on the car. Also, considering the size of the team, different teams might be using the car and the GPS team will always be the last team to get hold of the car.

==== Review of Parts used ====
The parts used for this controller were good and I would use them again.

== IO Controller ==

=== Summary ===

The IO controller's purpose is to display useful information on an LCD screen for debugging and verification purposes. Essentially, it monitors the CAN bus for other controllers' data as well as bus utilization. The hardware and software design is described below, as well as the challenges we encountered along the way.

=== Hardware Design ===

The hardware design of the IO controller is relatively simple. The only requirements are the serial LCD module and the controller itself. The LCD interfaces to the IO controller via UART protocol, while the IO controller interfaces to tater other controllers via CAN Protocol. The [[F14: Team5-Self Driving Car - AUG#Design & Implementation|block diagram]] above shows gives a clear description of the IO controller's place in the system.

The LCD chosen was a serial enabled 20x4 character display from [https://www.sparkfun.com/products/9568 Sparkfun]. It was chosen for it's larger character display (rather than 16x2) and because the serial "backpack was built into the PCB. This backpack is used because the display controller communicates with a parallel interface. The serial "backpack" or converter interfaces the parallel connections with a serial one and provides a low level API to control the display. An additional API was designed on top of this one to make programming simple and clear as well as implement some useful features (such as printing with printf style arguments). It operates on 5V, so it could not be powered by the controller itself and need to use one of the 5V supplies on the car.

=== Software Design ===

==== RX Task ====

The receiving task uses the interrupt driven CAN driver to process messages sent on the bus. When a CAN message is received, the data is filtered and stored a global memory locations. This data is later used by the IO task to format and print the desired information to the LCD. No hardware filter was used, since the IO controller must monitor bus utilization and therefore listen to all messages. No heavy calculations or blocking code is allowed in this task; it's purpose is to get the data out as fast as possible and wait for more.

==== LCD API ====

The LCD API uses a singleton template so that any task can invoke it and print something to the LCD. Since the LCD doesn't care who prints what, care must be taken to ensure other tasks' data isn't unintentionally overwritten. However, only a single task in our implementation is utilizing this API so it wasn't a problem. The LCD communicates over UART, so the available UART driver was used (also a singleton template). The data sheet from Sparkfun was used to create this API so that nearly all the LCD capabilities can be supported. These features include:

* Erase screen or individual line
* Write to screen, line or specific location
* Adjust backlight brightness
* Adjust cursor position and style
* Scroll text
* Turn display off or on
* Change baud rate

==== IO Task ====

[[File:CmpE243_F14_T5_LCDScreenDesign.png|700px|thumb|center|Fig. LCD screen object design]]

The IO task utilizes the LCD API to display LCD "screens". A screen is a custom-defined object containing "line" objects. Lines consist of a format sting (in the printf format) and optional variables. All screens are stored in a vector, of which the front object is always displayed on the LCD. To change the screen, the vector is simply rotated left or right (forward or backward). For simplicity, the screens are rotated every second. However the screens can be rotated by button press, timer, external interrupt or even CAN message.

The data objects that are stored in shared memory by the RX task make up the variables in the format strings described above. To accomplish this, the data types for these variables are char**, or a pointer to a char pointer. That way, we can just supply the memory location of the char* that is constantly being updated by the RX task. This simplifies the implementation of the IO Task and ensures the latest data is used when printing the screens.

(flow chart for IO Task)

== Controller Communication Table ==

{| class="wikitable"
|+ Controller ID Table
|-
! width="30" align="center"|Controller ID
! width="350" align="center"|Controller
|-
| 0x01
| Master Controller
|-
| 0x02
| Geographical Controller
|-
| 0x03
| Motor Controller
|-
| 0x04
| Sensor Controller
|-
| 0x05
| IO Controller
|-
| 0x06
| Communication (Bluetooth Bridge/Android App) Controller
|}

{| class="wikitable"
|+ Central Controller Communication Table
|-
! scope="col"| Sl. No
! scope="col"| Message Number
! scope="col"| Purpose
! scope="col"| Data layout
|-
! scope="row"|1
| 0x501
| Send Throttle and steering to motor
| throttle
steering
|-
! scope="row"| 2
| 0x502
| Start car
|
|-
! scope="row"| 3
| 0x503
| Stop car
|
|-
! scope="row"| 4
| 0x101
| Broadcast request revision
|
|-
! scope="row"| 5
| 0x102
| Broadcast Set time
|
|-
! scope="row"| 6
| 0x103
| Request TX count (broadcast)
|
|-
! scope="row"| 7
| 0x104
| Request RX count (broadcast)
|
|-
! scope="row"| 8
| 0x105
| Send TX count (LCD)
|
|-
! scope="row"| 9
| 0x106
| Send RX count (LCD)
|
|-
! scope="row"| 10
| 0x107
| All controllers initialize
|
|-
|}

{| class="wikitable"
|+ Communication (Bluetooth Bridge/Android App) Controller Communication Table
|-
! scope="col"| Sl. No
! scope="col"| Message Number
! scope="col"| Purpose
! scope="col"| Data layout
|-
! scope="row"|1
| 0x301
| Broadcast Start command
|
|-
! scope="row"| 2
| 0x302
| Broadcast Stop command
|
|-
! scope="row"| 3
| 0x303
| Broadcast GPS destination set by Android
|byte [0-3] : (float), Longitude
byte [4-7] : (float), Latitude
|-
|}

{| class="wikitable"
|+ Sensor Controller Communication Table
|-
! scope="col"| Sl. No
! scope="col"| Message Number
! scope="col"| Purpose
! scope="col"| Data layout
|-
! scope="row"|1
| 0x501
| Broadcast front sensors values
| byte[0]: Right ultrasonic sensor value in inches
byte[1]: Front ultrasonic sensor value in inches

byte[2]: Left ultrasonic sensor value in inches

byte[3]: Front bottom infrared sensor value in inches
|-
! scope="row"| 2
| 0x502
| Broadcast back infrared sensor value
| byte[0]: Back infrared sensor value in inches
|-
! scope="row"| 3
| 0x503
| Broadcast battery sensor value
|byte[0]: current/voltage sensor value in percentage
|-
! scope="row"| 4
| 0x504
| Broadcast light sensor value
|byte[0]: light sensor value as integer
|-
! scope="row"| 5
| 0x505
| Broadcast tilt sensor value
|byte[0]: X-Axis tilt sensor value as integer
byte[1]: Y-Axis tilt sensor value as integer

byte[2]: Z-Axis tilt sensor value as integer
|-
|}

{| class="wikitable"
|+ Motor/Servo Controller Communication Table
|-
! scope="col"| Sl. No
! scope="col"| Send Code
! scope="col"| Description
! scope="col"| Data
|-
! scope="row"|1
| 0x201
| Heartbeat data
| Controller id 1 byte
|-
! scope="row"| 2
| 0x201
| Heartbeat data
| Controller id 1 byte
|-
! scope="row"| 3
| 0x201
| Heartbeat data
| Controller id 1 byte
|-
! scope="row"| 4
| 0x202
| Mem info data
| Sys-mem remaining 4bytes
|-
! scope="row"| 5
| 0x501
| RPM data send
| RPM (2 bytes)
|-
! scope="row"| 6
| 0x502
| Speed data send
| Speed (2bytes)
|-
! scope="col"| Sl. No
! scope="col"| Receive Code
! scope="col"| Description
! scope="col"| Response
|-
! scope="row"| 1
| 0x300
| Kill
| Receive only
|-
! scope="row"| 2
| 0x301
| Stop
| Receive only
|-
! scope="row"| 3
| 0x302
| Straight
| Receive only
|-
! scope="row"| 4
| 0x307
| move forward 25%
| Receive only
|-
! scope="row"| 5
| 0x30C
| move forward 50%
| Receive only
|-
! scope="row"| 6
| 0x311
| move forward 75%
| Receive only
|-
! scope="row"| 7
| 0x315
| move forward 100%
| Receive only
|-
! scope="row"| 8
| 0x31A
| move backward 25%
| Receive only
|-
! scope="row"| 9
| 0x31F
| move backward 50%
| Receive only
|-
! scope="row"| 10
| 0x324
| move backward 75%
| Receive only
|-
! scope="row"| 11
| 0x329
| move backward 100%
| Receive only
|-
! scope="row"| 12
| 0x334
| Steer right 25%
| Receive only
|-
! scope="row"| 13
| 0x339
| Steer right 50%
| Receive only
|-
! scope="row"| 14
| 0x33E
| Steer right 75%
| Receive only
|-
! scope="row"| 15
| 0x343
| Steer right 100%
| Receive only
|-
! scope="row"| 16
| 0x348
| Steer Left 25%
| Receive only
|-
! scope="row"| 17
| 0x34D
| Steer left 50%
| Receive only
|-
! scope="row"| 18
| 0x352
| Steer left 75%
| Receive only
|-
! scope="row"| 19
| 0x357
| Steer left 100%
| Receive only
|-
|}

{| class="wikitable"
|+ Io Controller Communication Table
|-
! scope="col"| Sl. No
! scope="col"| Message Number
! scope="col"| Purpose
! scope="col"| Destination
|-
! scope="row"|1
| 0x301
| Start command for car
| Central Controller
|-
! scope="row"| 2
| 0x302
| Stop command for car
| Central Controller
|-
! scope="row"| 3
| 0x303
| Go to a predefined Destination.
| Central Controller
|}

== Testing & Technical Challenges ==
=== Sensors ===
The first challenge was the positioning and spacing between the sensors. The sensors were mounted on a 3D printed bracket for initial testing but the angle between the brackets seemed to cause interference and was not giving optimum values. The sensors were then individually mounted further apart to reduce interference. The detection distance was tweaked by trial and error and finally settled on the value of 36 inches for the front, left and right sensors and 7 inches for the back sensor.

The second challenge was dealing with erroneous values. Using ADC to interface sensors lead to certain erroneous values that didn't have the desired effect and after some testing, the sensor interface was changed to pulse width. This lead to more robust values after filtering.

Another challenge was the initial skewed alignment. It was difficult to detect whether the direction of the running car was changing because of the motor response to sensor values or the alignment of the tires. The group eventually decided to get a new car that rectified the alignment issue.

=== Sensors Configuration and Implementation ===
We used LV-MaxSonar series MB1010 high performance ultrasonic sensors for our application. The sensors detects objects from 6 inch to 254 inches and can be interfaced to ADC or pulse width output. We found the ADC values were inconsistent and due to the constraint of number of ADC pins on SJONE board , we used PWM to configure the sensors.
We mounted three sensors in front of the car and we found the values were not consistent as it was reflected from the ground, hence we elevated the sensor placement.
The sensor configuration is explained
[[File:CMPE243_F14_Group5_ultrasonic.png|200px|centre|thumb|Ultra SonicSensor]]

===Motor Controller ===

====Issue 1====
As we were using Electric Speed Control (ESC) to control the speed of motor we faced issues based on inconsistency of the speed. This could have been solved easily if we used H-bridge chip. When ESC was supplied with particular PWM signal it would work at desirable speed but when turning off the ESC and turning on the ESC the speed would change for the same PWM signal supplied. This inconsistency of the speed can easily damaged the motor as it was hard to predict when the motor will switch from forward to backward motion. So to fix this issue we had to connect the ESC to oscilloscope and turn on the transmitter. As soon as the transmitter is turned on the transmitter send a fix signal to ESC for some time that could have been in milli seconds. By doing this the ESC get initialized and once the ESC has initialized the transmitter can send a signal to go forward or reverse.

So we wrote a code to initialize the ESC. Before we sends the signal to ESC to move forward or reverse we send a fix PWM signal to ESC for one second to initialize ESC and this signal was sent from the main function.

====Issue 2====
The servo that came with the RC car wasn't fast enough to respond to left and right movement of the car. Car would hit the obstacle and than the wheel would rotate in opposite direction. So we change the servo with faster response time.

{| class="wikitable"
|-
! scope="col"|Sl. No
! scope="col"|Test Case
! scope="col"|Test Description
! scope="col"|Result
|-
| scope="row"|1||Initial CAN communication of all controllers ||Check if all the controllers are broadcasting the periodic message on CAN bus and receiving the data ||All controllers '''PASSED'''
|-
| scope="row"|2||Obstacle avoidance|| Obstacle by integrating the ultrasonic sensor||Obstacle avoidance '''PASSED'''
|-
| scope="row"|3||LCD display || Displying all the values including CPU Utilization, CAN message count, and message from the controllers ||LCD display of all message '''PASSED'''
|-
| scope="row"|4||Building Android application ||Check if the Android application sends the destination by Bluetooth||Communication '''PASSED'''
|-
| scope="row"|5||Point to Point movement || Test Car runs by setting two way points||Point to point car movement '''PASSED'''
|-
| scope="row"|6||Checking if Car runs with multiple way points ||Check if the car works with multiple way points||Multiple way points steering '''PASSED'''
|-
|}

== Challenges and Learning ==

== Future Enhancement ==
=== Sensors ===
It would be ideal to add another infrared sensor to the front lower portion of the car for cliff detection. It would also be good to have a bigger 3D printed bracket to mount the sensors that match our measurements requirements. This would add to the visual appeal and also reduce tangling mess due to the wires.

== Conclusion ==

== Project Video ==

Demo : http://youtu.be/a9ceLDJN67M

Teampics : http://youtu.be/TJW7AsHpXfE

== Project Source Code ==

== References ==
=== Acknowledgement ===

=== References Used ===
# Preetpal Kang, Lecture notes of CMPE 243, Computer Engineering, Charles W. Davidson College of Engineering, San Jose State University, Aug-Dec 2014.
# en.wikipedia.org/
# MaxBotix 2012, http://www.maxbotix.com/articles/031.htm

F14: Team5-Self Driving Car - AUG

2014-12-23T03:38:20Z

146S12T4: /* IO Controller */

== Self Driving Car ==

== Objective and Scope ==

This project is aimed at creating a self-driving car with obstacles avoidance and to steer to the gps location pointed by the android application with the help of multiple controllers communicating using CAN bus.CAN(Control Area Network) is a communication protocol used widely in automotive application developed by BOSCH in 1986. The self-driving car consists of 6 different controllers for '''GPS''','''Sensor''','''Central''','''Motor''','''IO''' and '''Communication'''. The controllers communicate to other controller by CAN bus.We have implemented broadcast algorithm to broadcast all the data from each controller in different frequencies. The controller parses the data using the 29 bit identifier which has destination and source address.

[[File:CmpE244_F14_SelfDrivingCarT5_basic_can_updated.JPG|700px|thumb|center|Fig 2. Build in Progress]]

== Team Members & Responsibilities ==

{| class="wikitable"
|-
! scope="col"| Sl. No
! scope="col"| Task
! scope="col"| Team Members
|-
! scope="row"| 1
| Sensor Controller
|
# Bailey Wu
# Rishabh Sareen
# Rishab H
|-
! scope="row"| 2
| Motor Controller
|
# Abhraham Ruiz
# Arpit Amin
# Sree Harsha
|-
! scope="row"| 3
| I/O Controller (LCD Display)
|
# Yoni Klein
# Tejeswar
|-
! scope="row"| 4
| Communication Bridge + Android
|
# Shaw Ken Chang
# Arnold Bajet Jr.
# Thomas Pantels
|-
! scope="row"| 5
| Geographical Controller
|
# Himanshu Saini
# Divya Kamath
|-
! scope="row"| 6
| Central Controller
|
# Divya Kamath
# Tejeswar
# Sree Harsha
|-
! scope="row"| 7
| Car design and wiring
|
# Bailey Wu
# Himanshu Saini
# Sree Harsha
# Karthik Vadiraja
# Akash Ayare
|-
! scope="row"| 8
| Git Setup
| Akash Ayare
|-
|}

== Introduction ==

The goal of this project was to design and implement a self-driving car. The team consisted of 15 people, divided into 6 teams corresponding to six controllers. The aim of this class was to understand the CAN protocol that is used extensively in vehicles. The self-driving car houses six controllers, all of them communicating using CAN. Each controller performs a unique task such as:
# '''Sensor Controller''': Interfaced to the front and back sensors. Periodically sends sensor data to the central controller. Crucial for obstacle detection and avoidance
# '''Motor Controller''': Controls the motors and steering of the car, based on commands received from central controller.
# '''Geographical Controller''': Interfaced to GPS and compass. Periodically sends location, heading and distance from destination. crucial for autonomous navigation of the car.
# '''Communication Controller''': Acts as a bridge for Android. Android app is used to set destination, calculate path to destination, start and stop the car. Data is sent to central and geographical Controller based on user input.
# '''Central Controller''': The brain of the car. Uses sensor and geographical data to steer the car in the right direction. Uses sensor data to detect and avoid obstacles. Uses geographical data to move towards desired location
# '''Display Controller''': Interfaced to an LCD screen which displays status of the car (reached/ not reached), CAN bus utilization, sensor data, bearing, heading etc.

== Schedule ==

'''Geographical Controller'''

{| class="wikitable"
|-
! scope="col"| Sl. No
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Actual Completion Date
|-
! scope="row"| 1
| 1-Oct-2014
| 14-Oct-2014
| Order Components and Make a schedule
| Completed
| 14-Oct-2014
|-
! scope="row"| 2
| 8-Oct-2014
| 14-Oct-2014
| Decide commands that Geographical Controller will support
| Completed
| 14-Oct-2014
|-
! scope="row"| 3
| 7-Oct-2014
| 14-Oct-2014
| Complete CAN RX task and subscription handling. Verify communication with other controllers
| Completed
| 21-Oct-2014
|-
! scope="row"| 4
| 14-Oct-2014
| 24-Oct-2014
| Interface GPS module and Compass and develop drivers if needed
| Completed
| 28-Oct-2014
|-
! scope="row"| 5
| 24-Oct-2014
| 30-Oct-2014
| Design and develop algorithm to calculate heading and bearing from GPS coordinates
| Completed.
| 30-Oct-2014
|-
! scope="row"| 6
| 24-Oct-2014
| 5-Nov-2014
| Work on calibration of compass and heading calculation
| Completed
| 11-Dec-2014
|-
! scope="row"| 7
| 1-Nov-2014
| 10-Nov-2014
| Test with the central and Bluetooth controller
| Completed
| 14-Dec-2014
|-
! scope="row"| 8
| 10-Nov-2014
| 25-Nov-2014
| Begin testing with fully assembled car
| Completed
| 1-Dec-2014
|-
|-
! scope="row"| 9
| 25-Nov-2014
| 10-Dec-2014
| Final Testing and changes as needed
| Completed
| 19-Dec-2014
|-
|}

'''Sensor Controller'''

{| class="wikitable"
|-
! scope="col"| Sl. No
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Actual Completion Date
|-
! scope="row"| 1
|10/3/2014
|10/10/2014
|Order ultrasonic sensor parts and develop simple test code for the sensors
|Done
|10/10/2014
|-
! scope="row"| 2
|10/10/2014
|10/17/2014
|Wire the ultrasonic sensors, develop and implement the sensors using analog to digital converter
|Done
|10/17/2014
|-
! scope="row"| 3
|10/17/2014
|10/24/2014
|Collaborate with the other sub teams to finish the CAN bus communication and allow the self driving car to drive autonomously
|Done
|10/24/2014
|-
|! scope="row"| 4
|10/24/2014
|11/1/2014
|Develop, implement and test the ultrasonic sensors using the pulse width modulation and universal asynchronous receiver/transmitter
|Done
|11/1/2014
|-
! scope="row"| 5
|11/2/2014
|11/9/2014
|Develop, implement and test the front and back infrared sensors using analog to digital converter
|Done
|11/9/2014
|-
! scope="row"| 6
|11/10/2014
|11/17/2014
|Develop, implement and test the current/voltage sensor for the battery packs of the self driving car using I2C
|Scheduled
|Removed
|-
! scope="row"| 7
|11/18/2014
|11/25/2014
|Collaborate with the other sub teams to make sure that the sensors are in working condition
|Done
|11/25/2014
|-
|-
! scope="row"| 8
|11/26/2014
|12/5/2014
|Collaborate with the other sub teams to debug any problems that may encountered
|Done
|12/5/2014
|-
! scope="row"| 9
|12/6/2014
|12/13/2014
|Prepare for demo
|Done
|12/19/2014
|-
|}

'''IO Controller'''

{| class="wikitable"
|-
! scope="col"| Sl. No
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Actual Completion Date
|-
|-
! scope="row"| 1
|10/7/2014
|10/14/2014
|Research and order LCD appropriate for this project
|Done
|10/11/2014
|-
|-
! scope="row"| 2
|10/7/2014
|10/17/2014
|Implement CAN RX/Subscription task
|Done
|10/13/2014
|-
|-
! scope="row"| 3
|10/7/2014
|10/17/2014
|Finalize Task Architecture
|Done
|11/1/2014
|-
|-
! scope="row"| 4
|10/18/2014
|10/21/2014
|Interface and test LCD
|Done
|10/20/2014
|-
|-
! scope="row"| 6
|10/21/2014
|10/28/2014
|Implement auto scrolling feature
|Done
|11/18/2014
|-
|}

'''Communication Bridge + Android'''

{| class="wikitable"
|-
! scope="col"| Sl. No
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Actual Completion Date
|-
! scope="row"| 1
| 16-Sep-2014
| 23-Sep-2014
| Test bluetooth module using computer serial port and an android app(simple bluetooth terminal app downloaded from google play). Test the real life range and stability of the bluetooth module (HC-06). Modify the bluetooth chat example to work with the bluetooth module.
| Done
| 20-Sep-2014
|-
! scope="row"| 2
| 28-Sep-2014
| 12-Oct-2014
| Draw UI design layouts for a basic android application that can view Google map as well as send GPS data through bluetooth by clicking on the map. Study google maps API and make a simple app that will post a short toast that shows the GPS location after a long press event.
| Done
| 12-Oct-2014
|-
! scope="row"| 3
| 7-Oct-2014
| 11-Oct-2014
| Interface bluetooth module with SJSUOne board and able to verify that the connection is stable and that transaction via the bluetooth is accurate. This is done by adding a test button where if you press the button it send a command to the board. After receiving the command, the board should react with a response (LED light and/or text response to the android phone)
| Done
| 19-Oct-2014
|-
! scope="row"| 4
| 11-Oct-2014
| 19-Oct-2014
|Integrate Google Maps and Bluetooth component together in Android app. After a long press on the map, the user should be prompted to start the car and set the location as the places the user selected. Add a textView to display the location selected by pressing on the map. Add a button for sending location to the car.
| Done
| 27-Oct-2014
|-
! scope="row"| 5
| 19-Oct-2014
| 26-Oct-2014
| CAN infrastructure implmentation: Use our team's common CAN infrasturcture code and modify it specifically for our controller. First created the CAN communication table and then modify the infracturacture code to implement the broacasting as well as filtering of neccessary data. This only focuses on broadcasting a stop/start command and the destination GPS data (set by android) as well as getting car's current location data from the geological controller.
|Done
| 07-Nov-2014
|-
! scope="row"| 6
| 26-Oct-2014
| 1-Nov-2014
| Test and implement car information reading as well as other functions of Android app
| In Progress
|
|-
! scope="row"| 7
| 2-Nov-2014
| 4-Nov-2014
| Iterate UI design
| In Progress
|
|-
! scope="row"| 8
| 5-Nov-2014
| 16-Nov-2014
| Implement 2nd UI design
| In Progress
|
|-
|}

'''Motor Controller'''

{| class="wikitable"
|-
! scope="col"| Sl. No
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Actual Completion Date
|-
|-
! scope="row"| 1
|10/1/2014
|10/8/2014
|PWM2 (used to control motors) and PWM3 (used to control servo) interface with the car servo and motor. Write a test code to operate the servo and motor from the terminal command.
|Completed and Tested
|10/11/2014
|-
|-
! scope="row"| 2
|10/9/2014
|10/18/2014
|Design and code CAN receive task for subscription. Check for basic CAN message commands for throttle and steer control.
|Completed and tested
|10/26/2014
|-
|-
! scope="row"| 3
|10/19/2014
|10/28/2014
|Design the CAN message table for motor control and servo control
|Completed and tested
|10/26/2014
|-
|-
! scope="row"| 4
|10/29/2014
|11/07/2014
|Design acceleration Vs steer control function for smooth run. Check for other factors involved.
|Completed and tested
|11/22/2014
|-
|-
! scope="row"| 5
|11/08/2014
|11/14/2014
|Research on RPM sensor. Interface the RPM sensor to calculate the Speed. Test the RPM sensor by running the car at different speed
|Completed and tested with a hall sensor
|11/22/2014
|-
|-
! scope="row"| 6
|11/15/2014
|11/21/2014
|Fine tune motor control code and integrate with all the controllers for proper working.
|Completed and tested
|11/22/2014
|-
|-
! scope="row"| 7
|11/22/2014
|11/28/2014
|Test and check if more features can be added to improve performance. Completed and tested
|Completed and tested
|11/28/2014
|-
|-
! scope="row"| 8
|11/29/2014
|12/05/2014
|Testing and Debugging.
|Completed and tested
|12/05/2014
|-
|-
!scope="row"|9
|12/06/2014
|12/18/2014
|Final Testing and getting the car ready for Demo.
|On Going
|

|}
'''Central Controller'''

{| class="wikitable"
|-
! scope="col"| Sl. No
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Actual Completion Date
|-
! scope="row"| 1
| 16-Sep-2014
| 23-Sep-2014
| Develop API for CAN bus communication.
| Done
| 23-Sep-2014
|-
! scope="row"| 2
| 11-Oct-2014
| 15-Oct-2014
| Develop communication table for all controllers.
| In Progress
|
|-
! scope="row"| 3
| 15-Oct-2014
| 20-Oct-2014
| Broadcast message and target message setup.
| Done
|
|-
! scope="row"| 4
| 21-Oct-2014
| 28-Oct-2014
| Co-ordinate all controllers and take major decisions.
| Done
|
|-
! scope="row"| 5
| 28-Oct-2014
| 11-Nov-2014
| Complete Building and fine-tuning of RC car.
| In Progress
|
|-
! scope="row"| 6
| 21-Oct-2014
| 11-Nov-2014
| Develop coordination mechanism to ensure controllers are initialized and ready
| In Progress
|
|-
! scope="row"| 7
| 21-Oct-2014
| 28-Oct-2014
| Develop kill switch
| Done
|
|-
! scope="row"| 8
| 14-Oct-2014
| 21-Oct-2014
| Build external power distribution circuit
| Done
| 21-Oct-2014
|-
! scope="row"| 9
| 28-Oct-2014
| 04-Nov-2014
| Coordination algorithm between steering and throttle for smooth turns
| In Progress
|
|-
! scope="row"| 10
| 04-Nov-2014
| 11-Nov-2014
| Collision avoidance algorithms
| Done
|
|-
! scope="row"| 11
| 04-Nov-2014
| 11-Nov-2014
| Intermediate unit and functional tests
| In Progress
|
|-
! scope="row"| 12
| 11-Nov-2014
| 25-Nov-2014
| Functional tests and algorithm adjustments
| In Progress
|
|-
! scope="row"| 13
| 25-Nov-2014
| 02-Dec-2014
| Fine tuning and stretch goals (headlights, parallel parking, etc.)
| Done
|
|-
! scope="row"| 14
| 02-Dec-2014
| 09-Dec-2014
| Prepare for demo
| In Progress
|
|-
|-

|}

== Parts List & Cost ==

{| class="wikitable"
! width="350" align="center"|Description
! width="30" align="center"|Qty
! width="60" align="center"|Price
|-
| LV-MaxSonar-EZ1 High Performance Ultrasonic Rangefinder
| 2
| 49.90
|-
| Analog Distance Sensor
| 1
| Free
|-
|1/10 Scale 4x4 Truck with Brushed Motor
|1
|217.33
|-
|2 ft 12-Gauge Power Cables
|3
|22.80
|-
|Pair Power Socket
|2
|2.16
|-
|Standard Size Body Clips
|12
|2.16
|-
|4-pack AA Batteries
|1
|3.45
|-
|50-pack M3x15mm Stand-Off Spacer Female-Male
|1
|11.19
|-
|100-pack 18-8 Flat Steel Washer
|1
|2.54
|-
|100-pack M3x20mm Hex-Drive Screw
|1
|6.47
|-
|100-pack M3 Steel Hex Nut
|1
|4.66
|-
|2-pin JST Connector Right Angle
|10
|6.84
|-
|4-pin JST Connector Right Angle
|10
|6.84
|-
|2-pin Female JST Cable (20 cm)
|10
|7.39
|-
|4-pin Female JST Cable (20 cm)
|10
|7.39
|-
|5 Volt Relay Breakout Board
|1
|4.95
|-
|5 Volt Voltage Regulator
|1
|1.07
|-
|Sharp Analog Distance Sensor 4-30 cm
|1
|9.95
|-
|3-pin Female JST PH-Style Cable (30 cm)
|1
|0.92
|-
|Double Sided Mounting Tape - 3 feet
|1
|4.35
|-
|AC Adapter (LiPo Charger)
|1
|15.16
|-
|IEC Power Cable (LiPo Charger)
|1
|5.38
|-
|4mm Bullet Plugs to Universal Plug
|1
|13.38
|-
|Acrylic sheet + Sharpe mini
|1+1
|11.72
|-
|Molex Pin Header, Connector, wires and 100 zip ties
|10+4+1
|17.13
|-
|2 x 90 degree pin header, 2 x straight pin header
|2+2
|3.65
|-
|uni-polar hall sensor for tachometer feedback
|2
|2.18
|-
|Heavy Duty magnets
|2
|4.18
|-
|INA219 Voltage sensors 26V +/-3.2A
|2
|19.9
|-
|-
|20x4 Serial LCD Module
|1
|29.99
|-
|}

== Backup Parts & cost ==

{| class="wikitable"
! width="30" align="center"|Qty
! width="350" align="center"|Description
! width="110" align="center"|Manufacturer
! width="60" align="center"|Part Number
! width="60" align="center"|Total Cost
|-
| 1
| LV-MaxSonar-EZ1 High Performance Ultrasonic Rangefinder
| MaxBotix Inc
| MB1010
| Free
|-
| 1
| Analog Distance Sensor
| Sharp
|
| Free
|-
|}

== Design & Implementation ==
[[File:CmpE243_F14_Team5_OverallHWDesign.jpg]]

== Motor Controller ==

==== Summary ====
This module takes command input from central controller and steers the car to its destination; in addition, It has two main controlling parameters : Throttle and Steering. Throttle input moves the car forward and backward. Steer input turns the wheel left and right. The central controller takes feedback from the sensors and makes decision to move the car. Accordingly, it sends CAN commands accepted by the motor controller for navigation, and real time RPM signal to the controller.

{| class="wikitable"
|+ Motor and Steer control : Technical Information
|-
! width="30" align="center"|Sl.No
! width="90" align="center"|Controller
! width="90" align="center"|Signal Type
! width="90" align="center"|Frequency
! width="350" align="center"|Functionality
|-
! scope="row"|1
| Motor Control
| PWM signal
| 50 Hz (20000us)
| 1000us (Full throttle forward) - 1500us (Stop) - 2000us (Full throttle backward)
|-
! scope="row"|2
| Steer Control
| PWM signal
| 50 Hz (20000us)
|1000us (Turn left max) - 1500us (Center) - 2000us (Turn right max)
|-
|}

===== Working =====
The car initially accepts the start command to begin navigation. Commands can then come to move the car forward or backward, steer left or right depending on intelligent decisions made by the central controller. The motor control has intelligence to avoid jerks and ensure smoother transitions between commands. The central controller gets the data from the sensors for obstacle avoidance. The car has a communication controller which gets the '''GPS''' data from the android application, the android application sets the destination latitude and longitude. The car decides the heading direction by the gps points and the compass and if it finds obstacle it will be controlled by the obstetrical avoidance and steer to the destination according to the algorithm below.
===== Flow Chart =====

[[File:Cmpe243_F14_T5_motor_controller_flowchart1.png]]

===== Kill switch =====
The remote control and receiver module pair up to provide a signal coverage of more than 100 meters. We make use of this to design our kill switch. When a constant PWM signal of 1000us is received from the remote, the car is in 'ARMED' state and moves the car according to CAN commands. The user has to hold the trigger gun for this state constantly and the car moves.
When the user releases the trigger gun, the car stops receiving the PWM signal of 1000us and the car goes to 'DISARMED' state.
In short, pull the trigger gun - ARMED, release the trigger gun - DISARMED.

===== RPM =====
The RPM sensor is based on a hall sensor switch which detect the North and South pole of a magnet located in the main shaft in the car. The hall sensor part number is 3177, and it has three pin. This sensor is uni-polar which give an output high signal when the sensor captures the North pole of the magnet; subsequently, the sensor give output low signal when the sensor captures the South pole of the magnet. Therefore, by using a the 3177 and a magnet in the shaft. the SJOne board can capture the output signal from the hall sensor as it toggles per shaft revolution.
It is important to notice that the output signal of the 3177 is an open collector; therefore, we need a 10 Kohm resistor connected to Vcc.

===== Pinout Table =====

The following table shows the pinout of all component that are connected to SJONE board.

{| class="wikitable"
|-
! scope="col"|No
! scope="col"|Description
! scope="col"|Component Pin
! scope="col"|Output Pin Source
|-
! scope="row"|1
|Hall Sensor (3177) Vcc ( 4.5 V to 18 V)
|Source
|SJOne P1_22
|-
! scope="row"|2
|Hall Sensor (3177) Ground
|Ground
|SJOne
|-
! scope="row"|3
|Hall Sensor (3177) Output
|Output
|SJOne P1_22 with a 10 KOhm
|-
!scope ="row"|4
|CAN Transceiver
|Pin # 1 TX
|SJOne P0_1(Tx)
|-
!scope ="row"|5
|CAN Transceiver
|Pin # 2 GND
|SJOne GND
|-
!scope ="row"|6
|CAN Transceiver
|Pin # 3 VCC
|SJOne 3.3v
|-
!scope ="row"|7
|CAN Transceiver
|Pin # 4 RX
|SJOne P0_0(Rx)
|-
!scope ="row"|8
|CAN Transceiver
|Pin # 6 CANL
|CAN Bus
|-
!scope ="row"|10
|CAN Transceiver
|Pin # 7 CANH
|CAN Bus
|-
!scope ="row"|11
|Servo
|VCC
|5V Power Rail
|-
!scope ="row"|12
|Servo
|GND
|GND Power Rail
|-
!scope ="row"|13
|Servo
|Signal
|PWM 2.1
|-
!scope ="row"|14
|Electric Speed Control (ESC)
|VCC
|5V Power rail
|-
!scope ="row"|15
|Electric Speed Control (ESC)
|GND
|GND Power Rail
|-
!scope ="row"|16
|Electric Speed Control (ESC)
|Signal
|PWM 2.2
|}

===== Block Diagram =====
The following Block diagram shows an overview of the connection between the SJOne board, ESC, and the Hall sensor:

[[File:Motor Block Diagram 1.jpg|600px|thumb|center|Motor Controller Block Diagram]]

== Sensor Controller ==
===Sensor Controller Hardware Design and Architecture ===
[[File:CmpE243 F14 T5 SensorHWDesign.JPG|700px|thumb| center |Fig . Sensor Controller Hardware Design]

When using multiple MaxSonar sensors, it is required to configure the sensors in ''Sequential Operation'' mode to obtain the best optimal performance in obstacle detection. On the other hand, if the sensors are left in continuous free run operation, which means the RX pin (Pin 4) are unconnected then at start-up the sensors will range at exactly the same time. Thus, the sensors are not synchronized and eventually result in frequency drifts that would likely cause interference between sensors for most applications.

[[File:CmpE243_F14_T5_SingleSensor.jpg|500px|thumb| center |Fig . Single Sensor in free run operation mode - MaxBotix 2012]]

The figure to the above shows a single MaxSonar ultrasonic sensor operating in continuous free run operation detecting an object at 96 inches. The signal of the ultrasonic sensor observe under the oscilloscope shows that the sensor is operating at its finesse performance without any interference.

The figure to the below shows that multiple MaxSonar ultrasonic sensors are operating in continuous free run operation. As you can see, the signal of a ultrasonic sensor observe under the oscilloscope shows that the signal has multiple spikes due to the interference of other sensors. Thus, the sensor becomes unsynchronized and the range reading become unstable.

[[File:CmpE243_F14_T5_MultipleSensorsInterferences.jpg‎|500px|thumb| center |Fig . Multiple Sensors in free run operation mode - MaxBotix 2012]]

To achieve the most optimal performance using multiple MaxSonar ultrasonic sensors, the figure below shows the implementation of all the sensors operating in sequential mode. The sensors can be started by pulling the RX pin (Pin 4) high for at least 20 uS and then for each reading this can be done as often as every 50 ms. This method would toggle each sensor when the user like to obtain an reading at any given moment. Thus, there will be no interference between each sensor.

[[File:CmpE243_F14_T5_MultipleSensorsConfiguration.jpg‎ |500px|thumb| center |Fig . Multiple Sensors Configuration]]

There are many other method to implement multiple MaxSonar ultrasonic sensors in a single system. This information can be obtained in the sensor datasheet.

===Sensor Controller Software Design===

== Central Controller ==

The central controller is the brain of the car. It receives information from all the other controllers and decides which direction the car must move. The central controller periodically sends commands to the motor regarding the throttle, steering, steering angle and speed.

In order to decide which direction to move, the central controller uses sensor data and geographical data. The current design uses a state machine. The car is initially in idle state. When it received a START command from the communication controller, the central sends the start motor command to the motor controller. After the start state, the central controller can be in one of the two states: avoid obstacle or adjust heading. The central controller uses the sensor data to detect obstacle. If there are no obstacles, then the central controller uses geographical information to adjust car heading.

Once the heading and bearing match, the car moves straight ahead till the destination is reached. When the geographical controller sends a command indicating that the car has reached the destination, the car will stop.

At any point during its course, if the car receives a STOP command from the communication controller, the car will stop

[[File:Cmpe243F14_Team5_Central_StateTransition.JPG|700px|thumb|center|Fig. Central Controller State Diagram]]

== Geographical Controller ==

The geographical controller is one of the six controllers mounted on the car. This controller provides the location and heading information to the central controller of the car. It also stores the destination (way-points). By calculating the distance from the current location to the destination or intermediate waypoint, the geo controller can determine if the car has reached its destination. When the car reaches the destination, the geo controller sends a message to the central controller indicating that destination has been reached.

The devices connected to this controller are:
1. Magnetometer (digital compass)
2. GPS Logger

The compass communicates via I2C and the GPS via UART.

==== Parts Used ====
{| class="wikitable"
|+ Geographical Control - Parts Used
|-
! align="center"|Part Number
! align="center"|Purpose
|-
| SparkFun Triple Axis Magnetometer Breakout - HMC5883L
| Compass
|-
| SparkFun Venus GPS Logger - SMA Connector
| GPS
|-
| Antenna GPS Embedded SMA - GPS-00177
| Antenna
|-
| ET-318 GPS Engine Board
| GPS
|}

==== Design ====

'''Heading''' - The compass provides the heading. The heading is the direction in which the car is headed. The value is typically an angle from 0-360 degrees measured clockwise from North. The heading is calculated from the x-axis and y-axis values provided by the magnetometer. To use all 3-axis values, a tilt sensor must be used with the magnetometer for tilt compensation.

'''GPS Module''' - The GPS module provides the time, latitude, longitude, direction and if the GPS data is valid. This latitude, longitude corresponds to the current location of the car.

'''Destination''' - The destination is set by Android application/communication controller. The destination could be a single point or a list of waypoints, each being a latitude, longitude pair.

'''Bearing''' - Using the destination lat,lon pair (set by the communication controller) and the current lat, lon pair (received from the GPS module), the geographical controller calculates the bearing. This angle, like the heading, is also typically between 0-360 degrees measured clockwise. Bearing represents the angle between the destination and current location.

Both the heading and the bearing are sent periodically to the central controller. The central controller uses this information combined with the sensor data to steer the motors in the right direction.

Example: If the current heading is 10 degrees ( car is travelling in a direction 10 degrees) from north. The bearing is 50 degrees ( the car is at an angle of 50 degrees away from the desired direction), the central controller must steer the car 40 degrees to the right.

The geographical controller also calculates the distance between the current lat, lon and the destination lat, lon. This is used to determine if the car has reached the intended destination. When the car has reached the destination, geographical controller sends a message to the central controller to stop.

==== Tasks ====
{| class="wikitable"
|+ Geographical Control - Tasks
|-
! align="center"|Task Name
! align="center"|Purpose
|-
| Compass Task
| Updates the compass heading. Runs every 100ms and obtains compass data over I2C
|-
| GPS Task
| Updates the current latitude and longitude by reading GPS data sent over UART. GPS has been configured to run at 10Hz and sends data at a baud rate of 38400.
|-
| CAN Rx Task
| Handles data received over CAN. Task gets blocked if can receive queue is empty.
|-
| CAN Periodic Msg Task
[1 Hz]
| Periodic CAN message to send current lat,lon and destination lat, lon to central and display controller
|-
| CAN Periodic Msg Task
[20 Hz]
| Periodic CAN message to send compass heading and destination bearing to central controller.
|}

==== GEO CAN Controller Communication Table ====
{| class="wikitable"
|+ Geographical Controller Communication Table
|-
! scope="col"| Message Number
! scope="col"| Message Type
! scope="col"| Purpose
! scope="col"| Data layout
|-
| 0x0301
| Get Geo Data
| Request for GPS Data (lat,long)
|
|-
| 0x0302
| "
| Request for current compass heading and destination heading
|
|-
| 0x0304
| "
| Request Time
|
|-
| 0x0601
| Response to 0x3xx request
| GPS Data (lat,long)
|
dword[0] : [32-bit latitude]
dword[1] : [32-bit longitude]
|-
| 0x0602
| "
| Compass heading and destination bearing
|
dword[0] : [32-bit compass heading]
dword[1] : [32-bit destination bearing]
|-
| 0x0504
| "
| Time
|
dword[0] : [32-bit time 0x00hhmmss]
|-
| 0x0501
| Periodic Message
| GPS data, broadcast periodically
|
dword[0] : [32-bit longitude]
dword[1] : [32-bit latitude]
|-
| 0x0502
| "
| Current and destination heading broadcast periodically
|
dword[0] : [32-bit compass heading]
dword[1] : [32-bit bearing]
|-

|}

==== Challenges and Lessons Learnt ====

# '''Start Geo work early''' : Most of the tasks of the geo controller can be done independent of the progress on the rest of the car. Start working early, test the GPS outside as much as possible.
# '''Compass calibration''' : Most compasses need calibration. During the course of our project, we used to magnetometers (since we accidently burned the first one). The first one was off by 5 degrees and the second one was off by about 20 degrees. Take care that the compass is mounted away from motors and other devices that can create a lot of noise for the compass
# '''GPS speed''' : We started by using the default speed of 1Hz on the GPS module. The data was sent to the central controller at 1 Hz. As we started testing we realized that this can be too slow and the car may go off course before the new data arrives. Using the commands in the datasheet, we configured the GPS to have an update rate of 10 Hz and a baud rate of 38400. While the datasheet said that the GPS can be configured for 20Hz and baud rate of 115200, we were unsuccessful in achieving that. For some reason, the SJOne board crashed every time we set the GPS for 115200. We did not successfully debug the issue. But changing the speed from 1Hz to 10Hz did make a lot of difference to the performance of the car steering.
# '''Picking the right GPS and compass''' : Both the compass and the GPS that we used served the purpose well. On sunny days, the GPS worked indoors too. Even though we used a 3 axis compass, we used only 2 axis readings from it to calculate the heading. A 3 axis compass paired with a tilt sensor would probably give better readings. But 2 axis readings served our purpose.
# '''GPS Drift''' : We noticed that the GPS values for the same locations drifted over time. There could be a 6 foot jump every few hours. The datasheet offers configurations to pin or unpin the gps values. We did not use the feature. But we did notice that because of the GPS drift, our car traveled differently on the same path at different times during the day. If we had more time, we could have fixed this and achieved a straight path for the car, instead of always veering to the left of right.
# '''Android App''' : The Android app is crucial since it provides the destination waypoints to the geo controller. We need to ensure that the dataset used by the android app is similar if not same as the values reported by the GPS. If the values differ a lot, then the car will not move along the intended path. The Android team and the GPS team must work closely and complete their testing well ahead, so that once the GPS and communication controllers are mounted it is only a matter of improving the behavior.
# '''Multiple Setups''' : Having multiple setups can be very helpful to debug issues, since it is easier to make changes on the temporary setup than on the car. Also, considering the size of the team, different teams might be using the car and the GPS team will always be the last team to get hold of the car.

==== Review of Parts used ====
The parts used for this controller were good and I would use them again.

== IO Controller ==

=== Summary ===

The IO controller's purpose is to display useful information on an LCD screen for debugging and verification purposes. Essentially, it monitors the CAN bus for other controllers' data as well as bus utilization. The hardware and software design is described below, as well as the challenges we encountered along the way.

=== Hardware Design ===

The hardware design of the IO controller is relatively simple. The only requirements are the serial LCD module and the controller itself. The LCD interfaces to the IO controller via UART protocol, while the IO controller interfaces to tater other controllers via CAN Protocol. The [[F14: Team5-Self Driving Car - AUG#Design & Implementation|block diagram]] above shows gives a clear description of the IO controller's place in the system.

The LCD chosen was a serial enabled 20x4 character display from [https://www.sparkfun.com/products/9568 Sparkfun]. It was chosen for it's larger character display (rather than 16x2) and because the serial "backpack was built into the PCB. This backpack is used because the display controller communicates with a parallel interface. The serial "backpack" or converter interfaces the parallel connections with a serial one and provides a low level API to control the display. An additional API was designed on top of this one to make programming simple and clear as well as implement some useful features (such as printing with printf style arguments). It operates on 5V, so it could not be powered by the controller itself and need to use one of the 5V supplies on the car.

=== Software Design ===

==== RX Task ====

The receiving task uses the interrupt driven CAN driver to process messages sent on the bus. When a CAN message is received, the data is filtered and stored a global memory locations. This data is later used by the IO task to format and print the desired information to the LCD. No hardware filter was used, since the IO controller must monitor bus utilization and therefore listen to all messages. No heavy calculations or blocking code is allowed in this task; it's purpose is to get the data out as fast as possible and wait for more.

(flow chart for RX task)

==== LCD API ====

The LCD API uses a singleton template so that any task can invoke it and print something to the LCD. Since the LCD doesn't care who prints what, care must be taken to ensure other tasks' data isn't unintentionally overwritten. However, only a single task in our implementation is utilizing this API so it wasn't a problem. The LCD communicates over UART, so the available UART driver was used (also a singleton template). The data sheet from Sparkfun was used to create this API so that nearly all the LCD capabilities can be supported. These features include:

* Erase screen or individual line
* Write to screen, line or specific location
* Adjust backlight brightness
* Adjust cursor position and style
* Scroll text
* Turn display off or on
* Change baud rate

==== IO Task ====

[[File:CmpE243_F14_T5_LCDScreenDesign.png|700px|thumb|center|Fig. LCD screen object design]]

The IO task utilizes the LCD API to display LCD "screens". A screen is a custom-defined object containing "line" objects. Lines consist of a format sting (in the printf format) and optional variables. All screens are stored in a vector, of which the front object is always displayed on the LCD. To change the screen, the vector is simply rotated left or right (forward or backward). For simplicity, the screens are rotated every second. However the screens can be rotated by button press, timer, external interrupt or even CAN message.

The data objects that are stored in shared memory by the RX task make up the variables in the format strings described above. To accomplish this, the data types for these variables are char**, or a pointer to a char pointer. That way, we can just supply the memory location of the char* that is constantly being updated by the RX task. This simplifies the implementation of the IO Task and ensures the latest data is used when printing the screens.

(flow chart for IO Task)

== Controller Communication Table ==

{| class="wikitable"
|+ Controller ID Table
|-
! width="30" align="center"|Controller ID
! width="350" align="center"|Controller
|-
| 0x01
| Master Controller
|-
| 0x02
| Geographical Controller
|-
| 0x03
| Motor Controller
|-
| 0x04
| Sensor Controller
|-
| 0x05
| IO Controller
|-
| 0x06
| Communication (Bluetooth Bridge/Android App) Controller
|}

{| class="wikitable"
|+ Central Controller Communication Table
|-
! scope="col"| Sl. No
! scope="col"| Message Number
! scope="col"| Purpose
! scope="col"| Data layout
|-
! scope="row"|1
| 0x501
| Send Throttle and steering to motor
| throttle
steering
|-
! scope="row"| 2
| 0x502
| Start car
|
|-
! scope="row"| 3
| 0x503
| Stop car
|
|-
! scope="row"| 4
| 0x101
| Broadcast request revision
|
|-
! scope="row"| 5
| 0x102
| Broadcast Set time
|
|-
! scope="row"| 6
| 0x103
| Request TX count (broadcast)
|
|-
! scope="row"| 7
| 0x104
| Request RX count (broadcast)
|
|-
! scope="row"| 8
| 0x105
| Send TX count (LCD)
|
|-
! scope="row"| 9
| 0x106
| Send RX count (LCD)
|
|-
! scope="row"| 10
| 0x107
| All controllers initialize
|
|-
|}

{| class="wikitable"
|+ Communication (Bluetooth Bridge/Android App) Controller Communication Table
|-
! scope="col"| Sl. No
! scope="col"| Message Number
! scope="col"| Purpose
! scope="col"| Data layout
|-
! scope="row"|1
| 0x301
| Broadcast Start command
|
|-
! scope="row"| 2
| 0x302
| Broadcast Stop command
|
|-
! scope="row"| 3
| 0x303
| Broadcast GPS destination set by Android
|byte [0-3] : (float), Longitude
byte [4-7] : (float), Latitude
|-
|}

{| class="wikitable"
|+ Sensor Controller Communication Table
|-
! scope="col"| Sl. No
! scope="col"| Message Number
! scope="col"| Purpose
! scope="col"| Data layout
|-
! scope="row"|1
| 0x501
| Broadcast front sensors values
| byte[0]: Right ultrasonic sensor value in inches
byte[1]: Front ultrasonic sensor value in inches

byte[2]: Left ultrasonic sensor value in inches

byte[3]: Front bottom infrared sensor value in inches
|-
! scope="row"| 2
| 0x502
| Broadcast back infrared sensor value
| byte[0]: Back infrared sensor value in inches
|-
! scope="row"| 3
| 0x503
| Broadcast battery sensor value
|byte[0]: current/voltage sensor value in percentage
|-
! scope="row"| 4
| 0x504
| Broadcast light sensor value
|byte[0]: light sensor value as integer
|-
! scope="row"| 5
| 0x505
| Broadcast tilt sensor value
|byte[0]: X-Axis tilt sensor value as integer
byte[1]: Y-Axis tilt sensor value as integer

byte[2]: Z-Axis tilt sensor value as integer
|-
|}

{| class="wikitable"
|+ Motor/Servo Controller Communication Table
|-
! scope="col"| Sl. No
! scope="col"| Send Code
! scope="col"| Description
! scope="col"| Data
|-
! scope="row"|1
| 0x201
| Heartbeat data
| Controller id 1 byte
|-
! scope="row"| 2
| 0x201
| Heartbeat data
| Controller id 1 byte
|-
! scope="row"| 3
| 0x201
| Heartbeat data
| Controller id 1 byte
|-
! scope="row"| 4
| 0x202
| Mem info data
| Sys-mem remaining 4bytes
|-
! scope="row"| 5
| 0x501
| RPM data send
| RPM (2 bytes)
|-
! scope="row"| 6
| 0x502
| Speed data send
| Speed (2bytes)
|-
! scope="col"| Sl. No
! scope="col"| Receive Code
! scope="col"| Description
! scope="col"| Response
|-
! scope="row"| 1
| 0x300
| Kill
| Receive only
|-
! scope="row"| 2
| 0x301
| Stop
| Receive only
|-
! scope="row"| 3
| 0x302
| Straight
| Receive only
|-
! scope="row"| 4
| 0x307
| move forward 25%
| Receive only
|-
! scope="row"| 5
| 0x30C
| move forward 50%
| Receive only
|-
! scope="row"| 6
| 0x311
| move forward 75%
| Receive only
|-
! scope="row"| 7
| 0x315
| move forward 100%
| Receive only
|-
! scope="row"| 8
| 0x31A
| move backward 25%
| Receive only
|-
! scope="row"| 9
| 0x31F
| move backward 50%
| Receive only
|-
! scope="row"| 10
| 0x324
| move backward 75%
| Receive only
|-
! scope="row"| 11
| 0x329
| move backward 100%
| Receive only
|-
! scope="row"| 12
| 0x334
| Steer right 25%
| Receive only
|-
! scope="row"| 13
| 0x339
| Steer right 50%
| Receive only
|-
! scope="row"| 14
| 0x33E
| Steer right 75%
| Receive only
|-
! scope="row"| 15
| 0x343
| Steer right 100%
| Receive only
|-
! scope="row"| 16
| 0x348
| Steer Left 25%
| Receive only
|-
! scope="row"| 17
| 0x34D
| Steer left 50%
| Receive only
|-
! scope="row"| 18
| 0x352
| Steer left 75%
| Receive only
|-
! scope="row"| 19
| 0x357
| Steer left 100%
| Receive only
|-
|}

{| class="wikitable"
|+ Io Controller Communication Table
|-
! scope="col"| Sl. No
! scope="col"| Message Number
! scope="col"| Purpose
! scope="col"| Destination
|-
! scope="row"|1
| 0x301
| Start command for car
| Central Controller
|-
! scope="row"| 2
| 0x302
| Stop command for car
| Central Controller
|-
! scope="row"| 3
| 0x303
| Go to a predefined Destination.
| Central Controller
|}

== Testing & Technical Challenges ==
=== Sensors ===
The first challenge was the positioning and spacing between the sensors. The sensors were mounted on a 3D printed bracket for initial testing but the angle between the brackets seemed to cause interference and was not giving optimum values. The sensors were then individually mounted further apart to reduce interference. The detection distance was tweaked by trial and error and finally settled on the value of 36 inches for the front, left and right sensors and 7 inches for the back sensor.

The second challenge was dealing with erroneous values. Using ADC to interface sensors lead to certain erroneous values that didn't have the desired effect and after some testing, the sensor interface was changed to pulse width. This lead to more robust values after filtering.

Another challenge was the initial skewed alignment. It was difficult to detect whether the direction of the running car was changing because of the motor response to sensor values or the alignment of the tires. The group eventually decided to get a new car that rectified the alignment issue.

=== Sensors Configuration and Implementation ===
We used LV-MaxSonar series MB1010 high performance ultrasonic sensors for our application. The sensors detects objects from 6 inch to 254 inches and can be interfaced to ADC or pulse width output. We found the ADC values were inconsistent and due to the constraint of number of ADC pins on SJONE board , we used PWM to configure the sensors.
We mounted three sensors in front of the car and we found the values were not consistent as it was reflected from the ground, hence we elevated the sensor placement.
The sensor configuration is explained
[[File:CMPE243_F14_Group5_ultrasonic.png|200px|centre|thumb|Ultra SonicSensor]]

===Motor Controller ===

====Issue 1====
As we were using Electric Speed Control (ESC) to control the speed of motor we faced issues based on inconsistency of the speed. This could have been solved easily if we used H-bridge chip. When ESC was supplied with particular PWM signal it would work at desirable speed but when turning off the ESC and turning on the ESC the speed would change for the same PWM signal supplied. This inconsistency of the speed can easily damaged the motor as it was hard to predict when the motor will switch from forward to backward motion. So to fix this issue we had to connect the ESC to oscilloscope and turn on the transmitter. As soon as the transmitter is turned on the transmitter send a fix signal to ESC for some time that could have been in milli seconds. By doing this the ESC get initialized and once the ESC has initialized the transmitter can send a signal to go forward or reverse.

So we wrote a code to initialize the ESC. Before we sends the signal to ESC to move forward or reverse we send a fix PWM signal to ESC for one second to initialize ESC and this signal was sent from the main function.

====Issue 2====
The servo that came with the RC car wasn't fast enough to respond to left and right movement of the car. Car would hit the obstacle and than the wheel would rotate in opposite direction. So we change the servo with faster response time.

{| class="wikitable"
|-
! scope="col"|Sl. No
! scope="col"|Test Case
! scope="col"|Test Description
! scope="col"|Result
|-
| scope="row"|1||Initial CAN communication of all controllers ||Check if all the controllers are broadcasting the periodic message on CAN bus and receiving the data ||All controllers '''PASSED'''
|-
| scope="row"|2||Obstacle avoidance|| Obstacle by integrating the ultrasonic sensor||Obstacle avoidance '''PASSED'''
|-
| scope="row"|3||LCD display || Displying all the values including CPU Utilization, CAN message count, and message from the controllers ||LCD display of all message '''PASSED'''
|-
| scope="row"|4||Building Android application ||Check if the Android application sends the destination by Bluetooth||Communication '''PASSED'''
|-
| scope="row"|5||Point to Point movement || Test Car runs by setting two way points||Point to point car movement '''PASSED'''
|-
| scope="row"|6||Checking if Car runs with multiple way points ||Check if the car works with multiple way points||Multiple way points steering '''PASSED'''
|-
|}

== Challenges and Learning ==

== Future Enhancement ==
=== Sensors ===
It would be ideal to add another infrared sensor to the front lower portion of the car for cliff detection. It would also be good to have a bigger 3D printed bracket to mount the sensors that match our measurements requirements. This would add to the visual appeal and also reduce tangling mess due to the wires.

== Conclusion ==

== Project Video ==

Demo : http://youtu.be/a9ceLDJN67M

Teampics : http://youtu.be/TJW7AsHpXfE

== Project Source Code ==

== References ==
=== Acknowledgement ===

=== References Used ===
# Preetpal Kang, Lecture notes of CMPE 243, Computer Engineering, Charles W. Davidson College of Engineering, San Jose State University, Aug-Dec 2014.
# en.wikipedia.org/
# MaxBotix 2012, http://www.maxbotix.com/articles/031.htm

F14: Team5-Self Driving Car - AUG

2014-12-23T01:21:45Z

146S12T4: /* IO Task */

== Self Driving Car ==

== Objective and Scope ==

This project is aimed at creating a self-driving car with obstacles avoidance and to steer to the gps location pointed by the android application with the help of multiple controllers communicating using CAN bus.CAN(Control Area Network) is a communication protocol used widely in automotive application developed by BOSCH in 1986. The self-driving car consists of 6 different controllers for '''GPS''','''Sensor''','''Central''','''Motor''','''IO''' and '''Communication'''. The controllers communicate to other controller by CAN bus.We have implemented broadcast algorithm to broadcast all the data from each controller in different frequencies. The controller parses the data using the 29 bit identifier which has destination and source address.

[[File:CmpE244_F14_SelfDrivingCarT5_basic_can_updated.JPG|700px|thumb|center|Fig 2. Build in Progress]]

== Team Members & Responsibilities ==

{| class="wikitable"
|-
! scope="col"| Sl. No
! scope="col"| Task
! scope="col"| Team Members
|-
! scope="row"| 1
| Sensor Controller
|
# Bailey Wu
# Rishabh Sareen
# Rishab H
|-
! scope="row"| 2
| Motor Controller
|
# Abhraham Ruiz
# Arpit Amin
# Sree Harsha
|-
! scope="row"| 3
| I/O Controller (LCD Display)
|
# Yoni Klein
# Tejeswar
|-
! scope="row"| 4
| Communication Bridge + Android
|
# Shaw Ken Chang
# Arnold Bajet Jr.
# Thomas Pantels
|-
! scope="row"| 5
| Geographical Controller
|
# Himanshu Saini
# Divya Kamath
|-
! scope="row"| 6
| Central Controller
|
# Divya Kamath
# Tejeswar
# Sree Harsha
|-
! scope="row"| 7
| Car design and wiring
|
# Bailey Wu
# Himanshu Saini
# Sree Harsha
# Karthik Vadiraja
# Akash Ayare
|-
! scope="row"| 8
| Git Setup
| Akash Ayare
|-
|}

== Introduction ==

The goal of this project was to design and implement a self-driving car. The team consisted of 15 people, divided into 6 teams corresponding to six controllers. The aim of this class was to understand the CAN protocol that is used extensively in vehicles. The self-driving car houses six controllers, all of them communicating using CAN. Each controller performs a unique task such as:
# '''Sensor Controller''': Interfaced to the front and back sensors. Periodically sends sensor data to the central controller. Crucial for obstacle detection and avoidance
# '''Motor Controller''': Controls the motors and steering of the car, based on commands received from central controller.
# '''Geographical Controller''': Interfaced to GPS and compass. Periodically sends location, heading and distance from destination. crucial for autonomous navigation of the car.
# '''Communication Controller''': Acts as a bridge for Android. Android app is used to set destination, calculate path to destination, start and stop the car. Data is sent to central and geographical Controller based on user input.
# '''Central Controller''': The brain of the car. Uses sensor and geographical data to steer the car in the right direction. Uses sensor data to detect and avoid obstacles. Uses geographical data to move towards desired location
# '''Display Controller''': Interfaced to an LCD screen which displays status of the car (reached/ not reached), CAN bus utilization, sensor data, bearing, heading etc.

== Schedule ==

'''Geographical Controller'''

{| class="wikitable"
|-
! scope="col"| Sl. No
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Actual Completion Date
|-
! scope="row"| 1
| 1-Oct-2014
| 14-Oct-2014
| Order Components and Make a schedule
| Completed
| 14-Oct-2014
|-
! scope="row"| 2
| 8-Oct-2014
| 14-Oct-2014
| Decide commands that Geographical Controller will support
| Completed
| 14-Oct-2014
|-
! scope="row"| 3
| 7-Oct-2014
| 14-Oct-2014
| Complete CAN RX task and subscription handling. Verify communication with other controllers
| Completed
| 21-Oct-2014
|-
! scope="row"| 4
| 14-Oct-2014
| 24-Oct-2014
| Interface GPS module and Compass and develop drivers if needed
| Completed
| 28-Oct-2014
|-
! scope="row"| 5
| 24-Oct-2014
| 30-Oct-2014
| Design and develop algorithm to calculate heading and bearing from GPS coordinates
| Completed.
| 30-Oct-2014
|-
! scope="row"| 6
| 24-Oct-2014
| 5-Nov-2014
| Work on calibration of compass and heading calculation
| Completed
| 11-Dec-2014
|-
! scope="row"| 7
| 1-Nov-2014
| 10-Nov-2014
| Test with the central and Bluetooth controller
| Completed
| 14-Dec-2014
|-
! scope="row"| 8
| 10-Nov-2014
| 25-Nov-2014
| Begin testing with fully assembled car
| Completed
| 1-Dec-2014
|-
|-
! scope="row"| 9
| 25-Nov-2014
| 10-Dec-2014
| Final Testing and changes as needed
| Completed
| 19-Dec-2014
|-
|}

'''Sensor Controller'''

{| class="wikitable"
|-
! scope="col"| Sl. No
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Actual Completion Date
|-
! scope="row"| 1
|10/3/2014
|10/10/2014
|Order ultrasonic sensor parts and develop simple test code for the sensors
|Done
|10/10/2014
|-
! scope="row"| 2
|10/10/2014
|10/17/2014
|Wire the ultrasonic sensors, develop and implement the sensors using analog to digital converter
|Done
|10/17/2014
|-
! scope="row"| 3
|10/17/2014
|10/24/2014
|Collaborate with the other sub teams to finish the CAN bus communication and allow the self driving car to drive autonomously
|Done
|10/24/2014
|-
|! scope="row"| 4
|10/24/2014
|11/1/2014
|Develop, implement and test the ultrasonic sensors using the pulse width modulation and universal asynchronous receiver/transmitter
|Done
|11/1/2014
|-
! scope="row"| 5
|11/2/2014
|11/9/2014
|Develop, implement and test the front and back infrared sensors using analog to digital converter
|Done
|11/9/2014
|-
! scope="row"| 6
|11/10/2014
|11/17/2014
|Develop, implement and test the current/voltage sensor for the battery packs of the self driving car using I2C
|Scheduled
|Removed
|-
! scope="row"| 7
|11/18/2014
|11/25/2014
|Collaborate with the other sub teams to make sure that the sensors are in working condition
|Done
|11/25/2014
|-
|-
! scope="row"| 8
|11/26/2014
|12/5/2014
|Collaborate with the other sub teams to debug any problems that may encountered
|Done
|12/5/2014
|-
! scope="row"| 9
|12/6/2014
|12/13/2014
|Prepare for demo
|Done
|12/19/2014
|-
|}

'''IO Controller'''

{| class="wikitable"
|-
! scope="col"| Sl. No
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Actual Completion Date
|-
|-
! scope="row"| 1
|10/7/2014
|10/14/2014
|Research and order LCD appropriate for this project
|Done
|10/11/2014
|-
|-
! scope="row"| 2
|10/7/2014
|10/17/2014
|Implement CAN RX/Subscription task
|Done
|10/13/2014
|-
|-
! scope="row"| 3
|10/7/2014
|10/17/2014
|Finalize Task Architecture
|Done
|11/1/2014
|-
|-
! scope="row"| 4
|10/18/2014
|10/21/2014
|Interface and test LCD
|Done
|10/20/2014
|-
|-
! scope="row"| 6
|10/21/2014
|10/28/2014
|Implement auto scrolling feature
|Done
|11/18/2014
|-
|}

'''Communication Bridge + Android'''

{| class="wikitable"
|-
! scope="col"| Sl. No
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Actual Completion Date
|-
! scope="row"| 1
| 16-Sep-2014
| 23-Sep-2014
| Test bluetooth module using computer serial port and an android app(simple bluetooth terminal app downloaded from google play). Test the real life range and stability of the bluetooth module (HC-06). Modify the bluetooth chat example to work with the bluetooth module.
| Done
| 20-Sep-2014
|-
! scope="row"| 2
| 28-Sep-2014
| 12-Oct-2014
| Draw UI design layouts for a basic android application that can view Google map as well as send GPS data through bluetooth by clicking on the map. Study google maps API and make a simple app that will post a short toast that shows the GPS location after a long press event.
| Done
| 12-Oct-2014
|-
! scope="row"| 3
| 7-Oct-2014
| 11-Oct-2014
| Interface bluetooth module with SJSUOne board and able to verify that the connection is stable and that transaction via the bluetooth is accurate. This is done by adding a test button where if you press the button it send a command to the board. After receiving the command, the board should react with a response (LED light and/or text response to the android phone)
| Done
| 19-Oct-2014
|-
! scope="row"| 4
| 11-Oct-2014
| 19-Oct-2014
|Integrate Google Maps and Bluetooth component together in Android app. After a long press on the map, the user should be prompted to start the car and set the location as the places the user selected. Add a textView to display the location selected by pressing on the map. Add a button for sending location to the car.
| Done
| 27-Oct-2014
|-
! scope="row"| 5
| 19-Oct-2014
| 26-Oct-2014
| CAN infrastructure implmentation: Use our team's common CAN infrasturcture code and modify it specifically for our controller. First created the CAN communication table and then modify the infracturacture code to implement the broacasting as well as filtering of neccessary data. This only focuses on broadcasting a stop/start command and the destination GPS data (set by android) as well as getting car's current location data from the geological controller.
|Done
| 07-Nov-2014
|-
! scope="row"| 6
| 26-Oct-2014
| 1-Nov-2014
| Test and implement car information reading as well as other functions of Android app
| In Progress
|
|-
! scope="row"| 7
| 2-Nov-2014
| 4-Nov-2014
| Iterate UI design
| In Progress
|
|-
! scope="row"| 8
| 5-Nov-2014
| 16-Nov-2014
| Implement 2nd UI design
| In Progress
|
|-
|}

'''Motor Controller'''

{| class="wikitable"
|-
! scope="col"| Sl. No
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Actual Completion Date
|-
|-
! scope="row"| 1
|10/1/2014
|10/8/2014
|PWM2 (used to control motors) and PWM3 (used to control servo) interface with the car servo and motor. Write a test code to operate the servo and motor from the terminal command.
|Completed and Tested
|10/11/2014
|-
|-
! scope="row"| 2
|10/9/2014
|10/18/2014
|Design and code CAN receive task for subscription. Check for basic CAN message commands for throttle and steer control.
|Completed and tested
|10/26/2014
|-
|-
! scope="row"| 3
|10/19/2014
|10/28/2014
|Design the CAN message table for motor control and servo control
|Completed and tested
|10/26/2014
|-
|-
! scope="row"| 4
|10/29/2014
|11/07/2014
|Design acceleration Vs steer control function for smooth run. Check for other factors involved.
|Completed and tested
|11/22/2014
|-
|-
! scope="row"| 5
|11/08/2014
|11/14/2014
|Research on RPM sensor. Interface the RPM sensor to calculate the Speed. Test the RPM sensor by running the car at different speed
|Completed and tested with a hall sensor
|11/22/2014
|-
|-
! scope="row"| 6
|11/15/2014
|11/21/2014
|Fine tune motor control code and integrate with all the controllers for proper working.
|Completed and tested
|11/22/2014
|-
|-
! scope="row"| 7
|11/22/2014
|11/28/2014
|Test and check if more features can be added to improve performance. Completed and tested
|Completed and tested
|11/28/2014
|-
|-
! scope="row"| 8
|11/29/2014
|12/05/2014
|Testing and Debugging.
|Completed and tested
|12/05/2014
|-
|-
!scope="row"|9
|12/06/2014
|12/18/2014
|Final Testing and getting the car ready for Demo.
|On Going
|

|}
'''Central Controller'''

{| class="wikitable"
|-
! scope="col"| Sl. No
! scope="col"| Start Date
! scope="col"| End Date
! scope="col"| Task
! scope="col"| Status
! scope="col"| Actual Completion Date
|-
! scope="row"| 1
| 16-Sep-2014
| 23-Sep-2014
| Develop API for CAN bus communication.
| Done
| 23-Sep-2014
|-
! scope="row"| 2
| 11-Oct-2014
| 15-Oct-2014
| Develop communication table for all controllers.
| In Progress
|
|-
! scope="row"| 3
| 15-Oct-2014
| 20-Oct-2014
| Broadcast message and target message setup.
| Done
|
|-
! scope="row"| 4
| 21-Oct-2014
| 28-Oct-2014
| Co-ordinate all controllers and take major decisions.
| Done
|
|-
! scope="row"| 5
| 28-Oct-2014
| 11-Nov-2014
| Complete Building and fine-tuning of RC car.
| In Progress
|
|-
! scope="row"| 6
| 21-Oct-2014
| 11-Nov-2014
| Develop coordination mechanism to ensure controllers are initialized and ready
| In Progress
|
|-
! scope="row"| 7
| 21-Oct-2014
| 28-Oct-2014
| Develop kill switch
| Done
|
|-
! scope="row"| 8
| 14-Oct-2014
| 21-Oct-2014
| Build external power distribution circuit
| Done
| 21-Oct-2014
|-
! scope="row"| 9
| 28-Oct-2014
| 04-Nov-2014
| Coordination algorithm between steering and throttle for smooth turns
| In Progress
|
|-
! scope="row"| 10
| 04-Nov-2014
| 11-Nov-2014
| Collision avoidance algorithms
| Done
|
|-
! scope="row"| 11
| 04-Nov-2014
| 11-Nov-2014
| Intermediate unit and functional tests
| In Progress
|
|-
! scope="row"| 12
| 11-Nov-2014
| 25-Nov-2014
| Functional tests and algorithm adjustments
| In Progress
|
|-
! scope="row"| 13
| 25-Nov-2014
| 02-Dec-2014
| Fine tuning and stretch goals (headlights, parallel parking, etc.)
| Done
|
|-
! scope="row"| 14
| 02-Dec-2014
| 09-Dec-2014
| Prepare for demo
| In Progress
|
|-
|-

|}

== Parts List & Cost ==

{| class="wikitable"
! width="350" align="center"|Description
! width="30" align="center"|Qty
! width="60" align="center"|Price
|-
| LV-MaxSonar-EZ1 High Performance Ultrasonic Rangefinder
| 2
| 49.90
|-
| Analog Distance Sensor
| 1
| Free
|-
|1/10 Scale 4x4 Truck with Brushed Motor
|1
|217.33
|-
|2 ft 12-Gauge Power Cables
|3
|22.80
|-
|Pair Power Socket
|2
|2.16
|-
|Standard Size Body Clips
|12
|2.16
|-
|4-pack AA Batteries
|1
|3.45
|-
|50-pack M3x15mm Stand-Off Spacer Female-Male
|1
|11.19
|-
|100-pack 18-8 Flat Steel Washer
|1
|2.54
|-
|100-pack M3x20mm Hex-Drive Screw
|1
|6.47
|-
|100-pack M3 Steel Hex Nut
|1
|4.66
|-
|2-pin JST Connector Right Angle
|10
|6.84
|-
|4-pin JST Connector Right Angle
|10
|6.84
|-
|2-pin Female JST Cable (20 cm)
|10
|7.39
|-
|4-pin Female JST Cable (20 cm)
|10
|7.39
|-
|5 Volt Relay Breakout Board
|1
|4.95
|-
|5 Volt Voltage Regulator
|1
|1.07
|-
|Sharp Analog Distance Sensor 4-30 cm
|1
|9.95
|-
|3-pin Female JST PH-Style Cable (30 cm)
|1
|0.92
|-
|Double Sided Mounting Tape - 3 feet
|1
|4.35
|-
|AC Adapter (LiPo Charger)
|1
|15.16
|-
|IEC Power Cable (LiPo Charger)
|1
|5.38
|-
|4mm Bullet Plugs to Universal Plug
|1
|13.38
|-
|Acrylic sheet + Sharpe mini
|1+1
|11.72
|-
|Molex Pin Header, Connector, wires and 100 zip ties
|10+4+1
|17.13
|-
|2 x 90 degree pin header, 2 x straight pin header
|2+2
|3.65
|-
|uni-polar hall sensor for tachometer feedback
|2
|2.18
|-
|Heavy Duty magnets
|2
|4.18
|-
|INA219 Voltage sensors 26V +/-3.2A
|2
|19.9
|-
|-
|20x4 Serial LCD Module
|1
|29.99
|-
|}

== Backup Parts & cost ==

{| class="wikitable"
! width="30" align="center"|Qty
! width="350" align="center"|Description
! width="110" align="center"|Manufacturer
! width="60" align="center"|Part Number
! width="60" align="center"|Total Cost
|-
| 1
| LV-MaxSonar-EZ1 High Performance Ultrasonic Rangefinder
| MaxBotix Inc
| MB1010
| Free
|-
| 1
| Analog Distance Sensor
| Sharp
|
| Free
|-
|}

== Design & Implementation ==
[[File:CmpE243_F14_Team5_OverallHWDesign.jpg]]

== Motor Controller ==

==== Summary ====
This module takes command input from central controller and steers the car to its destination; in addition, It has two main controlling parameters : Throttle and Steering. Throttle input moves the car forward and backward. Steer input turns the wheel left and right. The central controller takes feedback from the sensors and makes decision to move the car. Accordingly, it sends CAN commands accepted by the motor controller for navigation, and real time RPM signal to the controller.

{| class="wikitable"
|+ Motor and Steer control : Technical Information
|-
! width="30" align="center"|Sl.No
! width="90" align="center"|Controller
! width="90" align="center"|Signal Type
! width="90" align="center"|Frequency
! width="350" align="center"|Functionality
|-
! scope="row"|1
| Motor Control
| PWM signal
| 50 Hz (20000us)
| 1000us (Full throttle forward) - 1500us (Stop) - 2000us (Full throttle backward)
|-
! scope="row"|2
| Steer Control
| PWM signal
| 50 Hz (20000us)
|1000us (Turn left max) - 1500us (Center) - 2000us (Turn right max)
|-
|}

===== Working =====
The car initially accepts the start command to begin navigation. Commands can then come to move the car forward or backward, steer left or right depending on intelligent decisions made by the central controller. The motor control has intelligence to avoid jerks and ensure smoother transitions between commands. The central controller gets the data from the sensors for obstacle avoidance. The car has a communication controller which gets the '''GPS''' data from the android application, the android application sets the destination latitude and longitude. The car decides the heading direction by the gps points and the compass and if it finds obstacle it will be controlled by the obstetrical avoidance and steer to the destination according to the algorithm below.
===== Flow Chart =====

[[File:Cmpe243_F14_T5_motor_controller_flowchart1.png]]

===== Kill switch =====
The remote control and receiver module pair up to provide a signal coverage of more than 100 meters. We make use of this to design our kill switch. When a constant PWM signal of 1000us is received from the remote, the car is in 'ARMED' state and moves the car according to CAN commands. The user has to hold the trigger gun for this state constantly and the car moves.
When the user releases the trigger gun, the car stops receiving the PWM signal of 1000us and the car goes to 'DISARMED' state.
In short, pull the trigger gun - ARMED, release the trigger gun - DISARMED.

===== RPM =====
The RPM sensor is based on a hall sensor switch which detect the North and South pole of a magnet located in the main shaft in the car. The hall sensor part number is 3177, and it has three pin. This sensor is uni-polar which give an output high signal when the sensor captures the North pole of the magnet; subsequently, the sensor give output low signal when the sensor captures the South pole of the magnet. Therefore, by using a the 3177 and a magnet in the shaft. the SJOne board can capture the output signal from the hall sensor as it toggles per shaft revolution.
It is important to notice that the output signal of the 3177 is an open collector; therefore, we need a 10 Kohm resistor connected to Vcc.

===== Pinout Table =====

The following table shows the pinout of all component that are connected to SJONE board.

{| class="wikitable"
|-
! scope="col"|No
! scope="col"|Description
! scope="col"|Component Pin
! scope="col"|Output Pin Source
|-
! scope="row"|1
|Hall Sensor (3177) Vcc ( 4.5 V to 18 V)
|Source
|SJOne P1_22
|-
! scope="row"|2
|Hall Sensor (3177) Ground
|Ground
|SJOne
|-
! scope="row"|3
|Hall Sensor (3177) Output
|Output
|SJOne P1_22 with a 10 KOhm
|-
!scope ="row"|4
|CAN Transceiver
|Pin # 1 TX
|SJOne P0_1(Tx)
|-
!scope ="row"|5
|CAN Transceiver
|Pin # 2 GND
|SJOne GND
|-
!scope ="row"|6
|CAN Transceiver
|Pin # 3 VCC
|SJOne 3.3v
|-
!scope ="row"|7
|CAN Transceiver
|Pin # 4 RX
|SJOne P0_0(Rx)
|-
!scope ="row"|8
|CAN Transceiver
|Pin # 6 CANL
|CAN Bus
|-
!scope ="row"|10
|CAN Transceiver
|Pin # 7 CANH
|CAN Bus
|-
!scope ="row"|11
|Servo
|VCC
|5V Power Rail
|-
!scope ="row"|12
|Servo
|GND
|GND Power Rail
|-
!scope ="row"|13
|Servo
|Signal
|PWM 2.1
|-
!scope ="row"|14
|Electric Speed Control (ESC)
|VCC
|5V Power rail
|-
!scope ="row"|15
|Electric Speed Control (ESC)
|GND
|GND Power Rail
|-
!scope ="row"|16
|Electric Speed Control (ESC)
|Signal
|PWM 2.2
|}

===== Block Diagram =====
The following Block diagram shows an overview of the connection between the SJOne board, ESC, and the Hall sensor:

[[File:Motor Block Diagram 1.jpg|600px|thumb|center|Motor Controller Block Diagram]]

== Sensor Controller ==
===Using Multiple MaxSonar Sensors===

When using multiple MaxSonar sensors, it is required to configure the sensors in ''Sequential Operation'' mode to obtain the best optimal performance in obstacle detection. On the other hand, if the sensors are left in continuous free run operation, which means the RX pin (Pin 4) are unconnected then at start-up the sensors will range at exactly the same time. Thus, the sensors are not synchronized and eventually result in frequency drifts that would likely cause interference between sensors for most applications.

[[File:CmpE243_F14_T5_SingleSensor.jpg|500px|thumb| center |Fig . Single Sensor in free run operation mode - MaxBotix 2012]]

The figure to the above shows a single MaxSonar ultrasonic sensor operating in continuous free run operation detecting an object at 96 inches. The signal of the ultrasonic sensor observe under the oscilloscope shows that the sensor is operating at its finesse performance without any interference.

The figure to the below shows that multiple MaxSonar ultrasonic sensors are operating in continuous free run operation. As you can see, the signal of a ultrasonic sensor observe under the oscilloscope shows that the signal has multiple spikes due to the interference of other sensors. Thus, the sensor becomes unsynchronized and the range reading become unstable.

[[File:CmpE243_F14_T5_MultipleSensorsInterferences.jpg‎|500px|thumb| center |Fig . Multiple Sensors in free run operation mode - MaxBotix 2012]]

To achieve the most optimal performance using multiple MaxSonar ultrasonic sensors, the figure below shows the implementation of all the sensors operating in sequential mode. The sensors can be started by pulling the RX pin (Pin 4) high for at least 20 uS and then for each reading this can be done as often as every 50 ms. This method would toggle each sensor when the user like to obtain an reading at any given moment. Thus, there will be no interference between each sensor.

[[File:CmpE243_F14_T5_MultipleSensorsConfiguration.jpg‎ |500px|thumb| center |Fig . Multiple Sensors Configuration]]

There are many other method to implement multiple MaxSonar ultrasonic sensors in a single system. This information can be obtained in the sensor datasheet.

== Central Controller ==

The central controller is the brain of the car. It receives information from all the other controllers and decides which direction the car must move. The central controller periodically sends commands to the motor regarding the throttle, steering, steering angle and speed.

In order to decide which direction to move, the central controller uses sensor data and geographical data. The current design uses a state machine. The car is initially in idle state. When it received a START command from the communication controller, the central sends the start motor command to the motor controller. After the start state, the central controller can be in one of the two states: avoid obstacle or adjust heading. The central controller uses the sensor data to detect obstacle. If there are no obstacles, then the central controller uses geographical information to adjust car heading.

Once the heading and bearing match, the car moves straight ahead till the destination is reached. When the geographical controller sends a command indicating that the car has reached the destination, the car will stop.

At any point during its course, if the car receives a STOP command from the communication controller, the car will stop

[[File:Cmpe243F14_Team5_Central_StateTransition.JPG|700px|thumb|center|Fig. Central Controller State Diagram]]

== Geographical Controller ==

The geographical controller is one of the six controllers mounted on the car. This controller provides the location and heading information to the central controller of the car. It also stores the destination (way-points). By calculating the distance from the current location to the destination or intermediate waypoint, the geo controller can determine if the car has reached its destination. When the car reaches the destination, the geo controller sends a message to the central controller indicating that destination has been reached.

The devices connected to this controller are:
1. Magnetometer (digital compass)
2. GPS Logger

The compass communicates via I2C and the GPS via UART.

==== Parts Used ====
{| class="wikitable"
|+ Geographical Control - Parts Used
|-
! align="center"|Part Number
! align="center"|Purpose
|-
| SparkFun Triple Axis Magnetometer Breakout - HMC5883L
| Compass
|-
| SparkFun Venus GPS Logger - SMA Connector
| GPS
|-
| Antenna GPS Embedded SMA - GPS-00177
| Antenna
|-
| ET-318 GPS Engine Board
| GPS
|}

==== Design ====

'''Heading''' - The compass provides the heading. The heading is the direction in which the car is headed. The value is typically an angle from 0-360 degrees measured clockwise from North. The heading is calculated from the x-axis and y-axis values provided by the magnetometer. To use all 3-axis values, a tilt sensor must be used with the magnetometer for tilt compensation.

'''GPS Module''' - The GPS module provides the time, latitude, longitude, direction and if the GPS data is valid. This latitude, longitude corresponds to the current location of the car.

'''Destination''' - The destination is set by Android application/communication controller. The destination could be a single point or a list of waypoints, each being a latitude, longitude pair.

'''Bearing''' - Using the destination lat,lon pair (set by the communication controller) and the current lat, lon pair (received from the GPS module), the geographical controller calculates the bearing. This angle, like the heading, is also typically between 0-360 degrees measured clockwise. Bearing represents the angle between the destination and current location.

Both the heading and the bearing are sent periodically to the central controller. The central controller uses this information combined with the sensor data to steer the motors in the right direction.

Example: If the current heading is 10 degrees ( car is travelling in a direction 10 degrees) from north. The bearing is 50 degrees ( the car is at an angle of 50 degrees away from the desired direction), the central controller must steer the car 40 degrees to the right.

The geographical controller also calculates the distance between the current lat, lon and the destination lat, lon. This is used to determine if the car has reached the intended destination. When the car has reached the destination, geographical controller sends a message to the central controller to stop.

==== Tasks ====
{| class="wikitable"
|+ Geographical Control - Tasks
|-
! align="center"|Task Name
! align="center"|Purpose
|-
| Compass Task
| Updates the compass heading. Runs every 100ms and obtains compass data over I2C
|-
| GPS Task
| Updates the current latitude and longitude by reading GPS data sent over UART. GPS has been configured to run at 10Hz and sends data at a baud rate of 38400.
|-
| CAN Rx Task
| Handles data received over CAN. Task gets blocked if can receive queue is empty.
|-
| CAN Periodic Msg Task
[1 Hz]
| Periodic CAN message to send current lat,lon and destination lat, lon to central and display controller
|-
| CAN Periodic Msg Task
[20 Hz]
| Periodic CAN message to send compass heading and destination bearing to central controller.
|}

==== GEO CAN Controller Communication Table ====
{| class="wikitable"
|+ Geographical Controller Communication Table
|-
! scope="col"| Message Number
! scope="col"| Message Type
! scope="col"| Purpose
! scope="col"| Data layout
|-
| 0x0301
| Get Geo Data
| Request for GPS Data (lat,long)
|
|-
| 0x0302
| "
| Request for current compass heading and destination heading
|
|-
| 0x0304
| "
| Request Time
|
|-
| 0x0601
| Response to 0x3xx request
| GPS Data (lat,long)
|
dword[0] : [32-bit latitude]
dword[1] : [32-bit longitude]
|-
| 0x0602
| "
| Compass heading and destination bearing
|
dword[0] : [32-bit compass heading]
dword[1] : [32-bit destination bearing]
|-
| 0x0504
| "
| Time
|
dword[0] : [32-bit time 0x00hhmmss]
|-
| 0x0501
| Periodic Message
| GPS data, broadcast periodically
|
dword[0] : [32-bit longitude]
dword[1] : [32-bit latitude]
|-
| 0x0502
| "
| Current and destination heading broadcast periodically
|
dword[0] : [32-bit compass heading]
dword[1] : [32-bit bearing]
|-

|}

==== Challenges and Lessons Learnt ====

# '''Start Geo work early''' : Most of the tasks of the geo controller can be done independent of the progress on the rest of the car. Start working early, test the GPS outside as much as possible.
# '''Compass calibration''' : Most compasses need calibration. During the course of our project, we used to magnetometers (since we accidently burned the first one). The first one was off by 5 degrees and the second one was off by about 20 degrees. Take care that the compass is mounted away from motors and other devices that can create a lot of noise for the compass
# '''GPS speed''' : We started by using the default speed of 1Hz on the GPS module. The data was sent to the central controller at 1 Hz. As we started testing we realized that this can be too slow and the car may go off course before the new data arrives. Using the commands in the datasheet, we configured the GPS to have an update rate of 10 Hz and a baud rate of 38400. While the datasheet said that the GPS can be configured for 20Hz and baud rate of 115200, we were unsuccessful in achieving that. For some reason, the SJOne board crashed every time we set the GPS for 115200. We did not successfully debug the issue. But changing the speed from 1Hz to 10Hz did make a lot of difference to the performance of the car steering.
# '''Picking the right GPS and compass''' : Both the compass and the GPS that we used served the purpose well. On sunny days, the GPS worked indoors too. Even though we used a 3 axis compass, we used only 2 axis readings from it to calculate the heading. A 3 axis compass paired with a tilt sensor would probably give better readings. But 2 axis readings served our purpose.
# '''GPS Drift''' : We noticed that the GPS values for the same locations drifted over time. There could be a 6 foot jump every few hours. The datasheet offers configurations to pin or unpin the gps values. We did not use the feature. But we did notice that because of the GPS drift, our car traveled differently on the same path at different times during the day. If we had more time, we could have fixed this and achieved a straight path for the car, instead of always veering to the left of right.
# '''Android App''' : The Android app is crucial since it provides the destination waypoints to the geo controller. We need to ensure that the dataset used by the android app is similar if not same as the values reported by the GPS. If the values differ a lot, then the car will not move along the intended path. The Android team and the GPS team must work closely and complete their testing well ahead, so that once the GPS and communication controllers are mounted it is only a matter of improving the behavior.
# '''Multiple Setups''' : Having multiple setups can be very helpful to debug issues, since it is easier to make changes on the temporary setup than on the car. Also, considering the size of the team, different teams might be using the car and the GPS team will always be the last team to get hold of the car.

==== Review of Parts used ====
The parts used for this controller were good and I would use them again.

== IO Controller ==

=== Summary ===

The IO controller's purpose is to display useful information on an LCD screen for debugging and verification purposes. Essentially, it monitors the CAN bus for other controllers' data as well as bus utilization. The hardware and software design is described below, as well as the challenges we encountered along the way.

=== Hardware Design ===

(block diagram of sj one board and lcd + CAN interface)

The hardware design of the IO controller is relatively simple. The only requirements are the serial LCD module and the controller itself. The LCD interfaces to the IO controller via UART protocol, while the IO controller interfaces to tater other controllers via CAN Protocol.

The LCD chosen was a serial enabled 20x4 character display from [https://www.sparkfun.com/products/9568 Sparkfun]. It was chosen for it's larger character display (rather than 16x2) and because the serial "backpack was built into the PCB. This backpack is used because the display controller communicates with a parallel interface. The serial "backpack" or converter interfaces the parallel connections with a serial one and provides a low level API to control the display. An additional API was designed on top of this one to make programming simple and clear as well as implement some useful features (such as printing with printf style arguments). It operates on 5V, so it could not be powered by the controller itself and need to use one of the 5V supplies on the car.

=== Software Design ===

==== RX Task ====

The receiving task uses the interrupt driven CAN driver to process messages sent on the bus. When a CAN message is received, the data is filtered and stored a global memory locations. This data is later used by the IO task to format and print the desired information to the LCD. No hardware filter was used, since the IO controller must monitor bus utilization and therefore listen to all messages. No heavy calculations or blocking code is allowed in this task; it's purpose is to get the data out as fast as possible and wait for more.

(flow chart for RX task)

==== LCD API ====

The LCD API uses a singleton template so that any task can invoke it and print something to the LCD. Since the LCD doesn't care who prints what, care must be taken to ensure other tasks' data isn't unintentionally overwritten. However, only a single task in our implementation is utilizing this API so it wasn't a problem. The LCD communicates over UART, so the available UART driver was used (also a singleton template). The data sheet from Sparkfun was used to create this API so that nearly all the LCD capabilities can be supported. These features include:

* Erase screen or individual line
* Write to screen, line or specific location
* Adjust backlight brightness
* Adjust cursor position and style
* Scroll text
* Turn display off or on
* Change baud rate

==== IO Task ====

[[File:CmpE243_F14_T5_LCDScreenDesign.png|700px|thumb|center|Fig. LCD screen object design]]

The IO task utilizes the LCD API to display LCD "screens". A screen is a custom-defined object containing "line" objects. Lines consist of a format sting (in the printf format) and optional variables. All screens are stored in a vector, of which the front object is always displayed on the LCD. To change the screen, the vector is simply rotated left or right (forward or backward). For simplicity, the screens are rotated every second. However the screens can be rotated by button press, timer, external interrupt or even CAN message.

The data objects that are stored in shared memory by the RX task make up the variables in the format strings described above. To accomplish this, the data types for these variables are char**, or a pointer to a char pointer. That way, we can just supply the memory location of the char* that is constantly being updated by the RX task. This simplifies the implementation of the IO Task and ensures the latest data is used when printing the screens.

(flow chart for IO Task)

== Controller Communication Table ==

{| class="wikitable"
|+ Controller ID Table
|-
! width="30" align="center"|Controller ID
! width="350" align="center"|Controller
|-
| 0x01
| Master Controller
|-
| 0x02
| Geographical Controller
|-
| 0x03
| Motor Controller
|-
| 0x04
| Sensor Controller
|-
| 0x05
| IO Controller
|-
| 0x06
| Communication (Bluetooth Bridge/Android App) Controller
|}

{| class="wikitable"
|+ Central Controller Communication Table
|-
! scope="col"| Sl. No
! scope="col"| Message Number
! scope="col"| Purpose
! scope="col"| Data layout
|-
! scope="row"|1
| 0x501
| Send Throttle and steering to motor
| throttle
steering
|-
! scope="row"| 2
| 0x502
| Start car
|
|-
! scope="row"| 3
| 0x503
| Stop car
|
|-
! scope="row"| 4
| 0x101
| Broadcast request revision
|
|-
! scope="row"| 5
| 0x102
| Broadcast Set time
|
|-
! scope="row"| 6
| 0x103
| Request TX count (broadcast)
|
|-
! scope="row"| 7
| 0x104
| Request RX count (broadcast)
|
|-
! scope="row"| 8
| 0x105
| Send TX count (LCD)
|
|-
! scope="row"| 9
| 0x106
| Send RX count (LCD)
|
|-
! scope="row"| 10
| 0x107
| All controllers initialize
|
|-
|}

{| class="wikitable"
|+ Communication (Bluetooth Bridge/Android App) Controller Communication Table
|-
! scope="col"| Sl. No
! scope="col"| Message Number
! scope="col"| Purpose
! scope="col"| Data layout
|-
! scope="row"|1
| 0x301
| Broadcast Start command
|
|-
! scope="row"| 2
| 0x302
| Broadcast Stop command
|
|-
! scope="row"| 3
| 0x303
| Broadcast GPS destination set by Android
|byte [0-3] : (float), Longitude
byte [4-7] : (float), Latitude
|-
|}

{| class="wikitable"
|+ Sensor Controller Communication Table
|-
! scope="col"| Sl. No
! scope="col"| Message Number
! scope="col"| Purpose
! scope="col"| Data layout
|-
! scope="row"|1
| 0x501
| Broadcast front sensors values
| byte[0]: Right ultrasonic sensor value in inches
byte[1]: Front ultrasonic sensor value in inches

byte[2]: Left ultrasonic sensor value in inches

byte[3]: Front bottom infrared sensor value in inches
|-
! scope="row"| 2
| 0x502
| Broadcast back infrared sensor value
| byte[0]: Back infrared sensor value in inches
|-
! scope="row"| 3
| 0x503
| Broadcast battery sensor value
|byte[0]: current/voltage sensor value in percentage
|-
! scope="row"| 4
| 0x504
| Broadcast light sensor value
|byte[0]: light sensor value as integer
|-
! scope="row"| 5
| 0x505
| Broadcast tilt sensor value
|byte[0]: X-Axis tilt sensor value as integer
byte[1]: Y-Axis tilt sensor value as integer

byte[2]: Z-Axis tilt sensor value as integer
|-
|}

{| class="wikitable"
|+ Motor/Servo Controller Communication Table
|-
! scope="col"| Sl. No
! scope="col"| Send Code
! scope="col"| Description
! scope="col"| Data
|-
! scope="row"|1
| 0x201
| Heartbeat data
| Controller id 1 byte
|-
! scope="row"| 2
| 0x201
| Heartbeat data
| Controller id 1 byte
|-
! scope="row"| 3
| 0x201
| Heartbeat data
| Controller id 1 byte
|-
! scope="row"| 4
| 0x202
| Mem info data
| Sys-mem remaining 4bytes
|-
! scope="row"| 5
| 0x501
| RPM data send
| RPM (2 bytes)
|-
! scope="row"| 6
| 0x502
| Speed data send
| Speed (2bytes)
|-
! scope="col"| Sl. No
! scope="col"| Receive Code
! scope="col"| Description
! scope="col"| Response
|-
! scope="row"| 1
| 0x300
| Kill
| Receive only
|-
! scope="row"| 2
| 0x301
| Stop
| Receive only
|-
! scope="row"| 3
| 0x302
| Straight
| Receive only
|-
! scope="row"| 4
| 0x307
| move forward 25%
| Receive only
|-
! scope="row"| 5
| 0x30C
| move forward 50%
| Receive only
|-
! scope="row"| 6
| 0x311
| move forward 75%
| Receive only
|-
! scope="row"| 7
| 0x315
| move forward 100%
| Receive only
|-
! scope="row"| 8
| 0x31A
| move backward 25%
| Receive only
|-
! scope="row"| 9
| 0x31F
| move backward 50%
| Receive only
|-
! scope="row"| 10
| 0x324
| move backward 75%
| Receive only
|-
! scope="row"| 11
| 0x329
| move backward 100%
| Receive only
|-
! scope="row"| 12
| 0x334
| Steer right 25%
| Receive only
|-
! scope="row"| 13
| 0x339
| Steer right 50%
| Receive only
|-
! scope="row"| 14
| 0x33E
| Steer right 75%
| Receive only
|-
! scope="row"| 15
| 0x343
| Steer right 100%
| Receive only
|-
! scope="row"| 16
| 0x348
| Steer Left 25%
| Receive only
|-
! scope="row"| 17
| 0x34D
| Steer left 50%
| Receive only
|-
! scope="row"| 18
| 0x352
| Steer left 75%
| Receive only
|-
! scope="row"| 19
| 0x357
| Steer left 100%
| Receive only
|-
|}

{| class="wikitable"
|+ Io Controller Communication Table
|-
! scope="col"| Sl. No
! scope="col"| Message Number
! scope="col"| Purpose
! scope="col"| Destination
|-
! scope="row"|1
| 0x301
| Start command for car
| Central Controller
|-
! scope="row"| 2
| 0x302
| Stop command for car
| Central Controller
|-
! scope="row"| 3
| 0x303
| Go to a predefined Destination.
| Central Controller
|}

== Testing & Technical Challenges ==
=== Sensors ===
The first challenge was the positioning and spacing between the sensors. The sensors were mounted on a 3D printed bracket for initial testing but the angle between the brackets seemed to cause interference and was not giving optimum values. The sensors were then individually mounted further apart to reduce interference. The detection distance was tweaked by trial and error and finally settled on the value of 36 inches for the front, left and right sensors and 7 inches for the back sensor.

The second challenge was dealing with erroneous values. Using ADC to interface sensors lead to certain erroneous values that didn't have the desired effect and after some testing, the sensor interface was changed to pulse width. This lead to more robust values after filtering.

Another challenge was the initial skewed alignment. It was difficult to detect whether the direction of the running car was changing because of the motor response to sensor values or the alignment of the tires. The group eventually decided to get a new car that rectified the alignment issue.

=== Sensors Configuration and Implementation ===
We used LV-MaxSonar series MB1010 high performance ultrasonic sensors for our application. The sensors detects objects from 6 inch to 254 inches and can be interfaced to ADC or pulse width output. We found the ADC values were inconsistent and due to the constraint of number of ADC pins on SJONE board , we used PWM to configure the sensors.
We mounted three sensors in front of the car and we found the values were not consistent as it was reflected from the ground, hence we elevated the sensor placement.
The sensor configuration is explained
[[File:CMPE243_F14_Group5_ultrasonic.png|200px|centre|thumb|Ultra SonicSensor]]

===Motor Controller ===

====Issue 1====
As we were using Electric Speed Control (ESC) to control the speed of motor we faced issues based on inconsistency of the speed. This could have been solved easily if we used H-bridge chip. When ESC was supplied with particular PWM signal it would work at desirable speed but when turning off the ESC and turning on the ESC the speed would change for the same PWM signal supplied. This inconsistency of the speed can easily damaged the motor as it was hard to predict when the motor will switch from forward to backward motion. So to fix this issue we had to connect the ESC to oscilloscope and turn on the transmitter. As soon as the transmitter is turned on the transmitter send a fix signal to ESC for some time that could have been in milli seconds. By doing this the ESC get initialized and once the ESC has initialized the transmitter can send a signal to go forward or reverse.

So we wrote a code to initialize the ESC. Before we sends the signal to ESC to move forward or reverse we send a fix PWM signal to ESC for one second to initialize ESC and this signal was sent from the main function.

====Issue 2====
The servo that came with the RC car wasn't fast enough to respond to left and right movement of the car. Car would hit the obstacle and than the wheel would rotate in opposite direction. So we change the servo with faster response time.

{| class="wikitable"
|-
! scope="col"|Sl. No
! scope="col"|Test Case
! scope="col"|Test Description
! scope="col"|Result
|-
| scope="row"|1||Initial CAN communication of all controllers ||Check if all the controllers are broadcasting the periodic message on CAN bus and receiving the data ||All controllers '''PASSED'''
|-
| scope="row"|2||Obstacle avoidance|| Obstacle by integrating the ultrasonic sensor||Obstacle avoidance '''PASSED'''
|-
| scope="row"|3||LCD display || Displying all the values including CPU Utilization, CAN message count, and message from the controllers ||LCD display of all message '''PASSED'''
|-
| scope="row"|4||Building Android application ||Check if the Android application sends the destination by Bluetooth||Communication '''PASSED'''
|-
| scope="row"|5||Point to Point movement || Test Car runs by setting two way points||Point to point car movement '''PASSED'''
|-
| scope="row"|6||Checking if Car runs with multiple way points ||Check if the car works with multiple way points||Multiple way points steering '''PASSED'''
|-
|}

== Challenges and Learning ==

== Future Enhancement ==
=== Sensors ===
It would be ideal to add another infrared sensor to the front lower portion of the car for cliff detection. It would also be good to have a bigger 3D printed bracket to mount the sensors that match our measurements requirements. This would add to the visual appeal and also reduce tangling mess due to the wires.

== Conclusion ==

== Project Video ==

== Project Source Code ==

== References ==
=== Acknowledgement ===

=== References Used ===
# Preetpal Kang, Lecture notes of CMPE 243, Computer Engineering, Charles W. Davidson College of Engineering, San Jose State University, Aug-Dec 2014.
# en.wikipedia.org/
# MaxBotix 2012, http://www.maxbotix.com/articles/031.htm

File:CmpE243 F14 T5 LCDScreenDesign.png

2014-12-23T01:19:45Z

146S12T4:

2012-05-25T19:59:34Z

146S12T4: /* Testing & Technical Challenges */

== FreeRTOS-based Quadrocopter with Real-Time Flight Data==
[[File:cmpe146_s12_t4_copter.jpg|700px|thumb|center|alt=FreeRTOS based QuadCopter|Our Very Own FreeRTOS based QuadCopter]]

== Abstract ==
Our CmpE 146 project involves the assembly of a FreeRTOS -based quadrocopter. Our quadrocopter will be able to provide real-time flight diagnostic data with the help of a couple of XBees. The quadrotor will house one of the XBees and the other XBee will be connected to an ARM LPC2148 board that is on the ground, next to the person flying. Data received on the local board is communicated to the host PC over UART. Flight is made possible with the help of generic radio control (or RC), and the inputs will be sent from the transmitter to the receiver. A flight controller board will receive those inputs and make the necessary adjustments to implement the desired function.

== Objectives & Introduction ==

Our team wanted to build a custom quadcopter that is governed by a FreeRTOS-based firmware. Our team used the [http://abusemark.com/store/index.php?main_page=product_info&cPath=1&products_id=30 Afroflight Naze32] flight controller, which has a 32-bit ARM Cortex M3 based processor. The firmware for it is based on a very popular codebase called [http://www.multiwii.com MultiWii] originally developed for commanding and controlling a quadcopter with Nintendo's Wii peripherals. The board contains 2 UART outputs - one for the USB-to-Serial converter for easy setting up and debugging with a PC. For the second UART to be available, this USB-to-Serial bridge has to be bypassed and replaced with [http://ftp1.digi.com/support/documentation/90000866_C.pdf XBee] since for some reason the current iteration of the board does not support multiple simultaneous UART channels.

Data sent over this UART is received via Xbee on the LPC2148 board which can then be retransmitted over another UART channel. This re-routed data can be monitored using the popular C#-.NET based GUI front end called [http://code.google.com/p/afrodevices/source/checkout mw-wingui] (MultiWii WinGUI). The program looks for data from the flight controller over the available COM ports and grabs packets of data which are then parsed and displayed on the screen appropriately. The data can also be received over Hercules with the help of a custom parser.

[[File:cmpe146_s12_t4_fc.jpg|thumb|right|alt=Flight Controller|Naze32 FunFly Flight Controller]]

A picture of the flight controller is shown to the right - it is extremely small, measuring 36mm x 36mm and features a rich variety of sensors:
*MEMS Gyroscope
*MEMS Accelerometer
*3-axis Magnetometer
*Pressure Sensor

Inputs are received from a rather old Futaba Conquest Transmitter [http://manuals.hobbico.com/fut/6nfk-6npk-manual.pdf FP-T6NPK] operating at 72MHz. The transmitter encodes the PWM waves as PCM, generally using a 1024 bit resolution. This signal is decoded by the receiver that usually comes with the transmitter (hence the reason why datasheets for receivers alone are hard to find - they are generally paired with a corresponding transmitter which generally also has a datasheet). The output from the receiver is pure PPM for every channel.

=== Team Members ===
*Yoni Klein
*Amol Mundayoor
*Raymond Buckman
*Michael Leung

=== Roles & Responsibilities ===

Amol Mundayoor - Parts research and acquisition, Parts assembly

Michael Leung - Software integration, Parts assembly

Raymond Buckman - Flying mechanics research, Parts assembly

Yoni Klein - Software integration, Parts assembly

== Parts List & Cost ==
{| class="wikitable"
|-
! PARTS
! COST
|-
| FunFly Naze32
| $70
|-
| ARM LPC2148 board
| $90
|-
| 4x 924kV motors
| $80 ($20 each)
|-
|4x DYS 30A ESC
|$72 ($18 each)
|-
|2x APC 1047 Propellers (Counterweighted Set)
|$15 ($7.50 each)
|-
|ST450 Aluminum Quadcopter Frame
| $35
|-
|2200 mAh LiPo Battery
|$20
|-
|LiPo Battery Charger
| $40
|-
| PCM Receiver/Transmitter
| Borrowed (nominally $50-$100)
|}

== Design & Implementation ==

=== The Copter Build Instructions ===
Assuming that all the parts have been gathered, here is the relatively detailed instruction set on how to go about building this quadcopter. When done, the copter will have the wheelbase (diameter of the quadcopter when measured from the axis of any two opposing propellers) of the frame (450mm).

===== Motor Installation =====
[[File:cmp146_s12_t4_motors.jpg|thumb|right|alt=The motors used in the build.|KA 20-22L 924kV motor]]

The picture on the right show the motor used, along with all the parts that come with it. The three black wires coming out of the motors go to the Electronic Speed Control (ESC). The order of the wires do not matter if you are using brushless motors and brushless ESCs (which is what you should be using on quadcopter builds anyway!). The four-pronged eight-holed plate goes under the motor between the frame - it's the motor mounting plate. The steel "crown" on the bottom right hand side next to the heatshrink is the propeller mount - it goes on top of the shaft, propeller goes on top, and the nut is tightened down so that the props don't come off during flight. There are some extraneous parts in the kit that can be considered as "spares".

===== Motor Mounting =====
Once the motor is assembled, they can be simply mounted on the frame using the motor mounting plate as described in the previous section. It is pretty straight forward - washers and lock nuts can be used to eliminate vibration since motors are the ones providing the most of the vibration in a copter system. '''DO NOT MOUNT THE PROPELLERS UNTIL THE VERY END - ONLY WHEN THE COPTER IS READY FOR FLIGHT TEST'''

===== ESC Connections =====
[[File:Cmpe146_s12_t4_esc.jpg|thumb|right|alt=Stupid ESC|DYS/RCTimer 30A ESC]]

The three blue wires coming out from the ESC are to be connected to the 3 wires on the motor. These connections have to be very well made because they'll be handling many many amps of current. Extending the wires were not necessary, and we recommend not extending them until absolutely necessary. The red and black wires are the battery wires - red is positive and black is ground. These connections are done using [http://helifreak.com/attachment.php?attachmentid=243211&stc=1&d=1311993095 bullet connectors] and [http://www.youtube.com/watch?v=B9yY9Kk4bEA here] is an excellent tutorial on how to solder them. Once those connections are done, the only wire left to take care of is the 3-pin wire. We recommend buying ESCs that have a BEC (Battery Eliminator Circuit) in them. When connecting such ESCs, only have the red wire from one ESC connected - all the other red wires from the other three ESCs are to remain disconnected.

[[File:cmpe146_s12_t4_escconections.jpg|200px|thumb|center|alt=Electronic Speed Controller Connections|Interface between Motor and Battery Through ESCs]]

ESCs are '''REQUIRED''' to be calibrated before using. There are different ways of calibrating an ESC depending on the brand and model. ESCs need to be calibrated individually. There are more information about ESCs calibrations online.

===== Flight Controller Connections =====
[[File:Cmp146_s12_t4_fc_con.jpg|thumb|right|alt=Connections|Naze32 Connection Interface]]

The picture on the right shows the flight controller connection interface. The manual on the abusemark store has more detailed information about what the flight controller is capable of. For our purposes the 3-pin header on top of the flight controller is sending the signal to the ESCs which then control the motors. The signals come from the RC Input headers, with the * being 5V, the 8 pins to the right being RC signal from the RC Receiver and the lone pin on the left is ground. Our Xbee was also powered using this 5V connector.

===== Power Distribution =====

[[File:cmpe146_s12_t4_battery.jpg|200px|thumb|center|alt=Voltz 11.1V 3s 2200mAh Battery|Voltz 11.1V 3s 2200mAh Battery]]

Power distribution can be tricky - we have one main source of power, which is a LiPo battery. This lone source is to be distributed among the ESCs - the best way to do this is with the help of a [http://www.youtube.com/watch?v=Tn2Nt3sjsI0 power spider]. Once the spider is made, the connections are super straightforward and simple - power goes to power and ground goes to ground.

[[File:cmp146_s12_t4_wiringharness.JPG|200px|thumb|center|alt=Wiring Harness|Wiring Harness]]

=== Hardware Design ===

The quadrocopter consists of a frame, a flight controller board, battery, RC receiver, four motors, and four propellers. All the components are mounted on the aluminum frame, which is “X”-shaped. There are three major components mounted at the center of the frame. They are: the Naze32 flight controller board, the battery and the RC receiver. A motor is mounted at the end of each arm of the frame. The flight controller board and battery are interfaced with the motors through electronic speed controllers (or ESCs). ESCs are responsible for controlling the speed and direction of each motor. Each motor is equipped with a 10 inch diameter propeller. A propeller’s measurements are designated by their diameters and pitch. The propeller’s diameter size determines the thrust power. A larger propeller generally generates more thrust than a smaller propeller at the same RPM. When a propeller spins at a high RPM, it will generate more noise and vibration. The pitch determines how far the propeller will move per single revolution of the motor. It is important to note that propellers that sit opposite of each other rotate the same direction. Therefore, one pair of propellers will be rotating clockwise while another pair will be rotating counterclockwise.

Quadrocopter movement is controlled by the motor rotation speed. Obvious movements, such as vertical movement, are controlled by increasing or decreasing the rpm of all four motors. To push the quadrocopter in a certain direction horizontally is done by only adjusting the motors along the axis of movement. The rotation speed of the motor that “pushes” the quadrocopter in a certain direction is increased, while the opposite motor’s rotation speed is decreased. As said earlier, the other two motor speeds are not adjusted. Calibrating all four motors in this fashion forces the quadrocopter to lean toward the side of the motor with the lowest rotation speed, and moves it in that direction. To rotate the quadrocopter in a certain direction, the motors of the propeller rotating in that direction need to be increased. Pitch and roll are accomplished by performing the same action as moving the quadrocopter horizontally.

[[File:cmpe146_s12_t4_frame.JPG|thumb|left|alt=The ST450 frame used in the build.|The ST450 frame used in the build.]]

The frame used was a factory made ST450 frame from Hobbycool. The frame is made in China and has some amount of portability - there are hex nuts that can be loosed to change the X format of the copter to an = format by folding the legs. The drawback is that the nuts have to be tightened every time the copter is to be flown. This can be quite inconvenient especially when all the parts are mounted. Hence a folding copter frame does not add any value to the build and can sometimes be conceived as less ideal. The frame comes with 4 10" propellers but they did not fit the motors we had (and better propellers were on hand).

The motors shown in the picture on the left are not the motors used in this build. The motors used in this build are shown on the right, and they produce 924rpm per volt (unit is kV, not to be confused with kiloVolt). This means that when powered with the minimum 7V each motors spin at approximately 6500rpm. When testing the copter it is now clear that the propellers should be removed. It also makes it easier to work around the little corners since there is minimal space.

[[File:cmpe146_s12_t4_props.jpg|thumb|right|alt=Propellers|APC 10x4.7 Propeller Set (Matched)]]

The propellers used were molded plastic propellers since they provided the best cost to performance ratio. The propellers come in matched sets - one rotates clockwise and the other rotates counter clockwise. The matched set has propellers identified as 10x4.7P and 10x4.7 - the propellers marked as P are "pushers" where they rotate counter-clockwise.

=== Hardware Interface ===

The flight controller used is called "Naze32" - it is based on an ARM Cortex M3 32-bit microcontroller. The firmware is available as an open source project hosted at [http://code.google.com/p/afrodevices/source/checkout Google Code] which can be checked out using subversion (or browsed using the "Browse" link). The firmware communicates with [http://www.multiwii.com/faq MultiWii] and its .NET GUI counterpart [http://code.google.com/p/mw-wingui/ MultiWii-WinGUI]. WinGUI communicates over UART to get data from the flight controller, and has a real time graphical representation of data being fed to the speed controllers and motors, along with the strength of RC input. RC input varies from 1000 - 2000, measured in milliseconds due to the nature of a PWM/PPM pulse.

The Naze32 Flight controller board is the intersection of all connections. Everything that is used to operate the quadrocopter is essentially linked to it. To have the quadrocopter perform a function, we need to tell it what to do first. This is done by using the RC transmitter (remote controller). The RC transmitter uses radio signals to communicate with the RC receiver, which is mounted on the quadrocopter frame. When the joysticks of the RC transmitter are moved, it completes a circuit to an IC, which generates a set sequence of electrical pulses. The sequence contains a set of pulses that corresponds the movement, indicated by the joysticks on the RC transmitter. The RC receiver receives these sequences of pulses and decodes them. Depending on the width of each pulse in a set sequence, the function of the quadrocopter will change. This kind of communication-control technique is called PWM, pulse width modulation. An analogy of this technique would be two friends trying to communicate with each other by whistling. Depending on the duration of the whistle, a different message will be delivered. For example, a continuous whistle of 2 seconds could mean “walk forward” and 5 seconds could mean “walk backward”.

The RC receiver sends the decoded PWM to the flight controller and then it powers the ESCs accordingly. The connections of the ESCs play a vital role in powering everything. The ESCs in our inventory are integrated with BECs, Battery Eliminator Circuit. BECs allows the flight controller board and RC receiver to be powered without an extra battery. Here’s how it works: the main battery is connected to the ESCs and the ESCs uses that same battery supply to power the board. This is done by connecting one (one is all that’s needed) of the ESCs’ BEC wire to the flight controller.

On the other end of the ESCs are three of the same wires. These wires are used to power the brushless motor. These three wires can be connected one-to-one to the wires of the brushless motor in any combination. When connected and powered, the brushless motors will spin in one direction. If you are not satisfied with the direction of the motor, then this could be change by switching connection between any 2 of the 3 wires.

[[File:cmpe146_s12_t4_blockdiagram.jpg|700px|thumb|center|alt=Quadrocopter Block Diagram|Quadrocopter Block Diagram shows the connection between the hardware components]]

=== Software Design and Implementation ===

Our flight controller board uses FreeRTOS to control communication between sensors and peripheral devices. The code for this board is GPL based and we have utilized it for this project. Our goal was to interface this board with our LPC2148 board for debugging and data logging. We also interfaced our boards with an already existant GUI software that shows real time flight data and sensor readouts. Communication from the flight controller board to the LPC2148 board and GUI was made over UART using a drop-in XBee wireless UART bridge. The ultimate goal was to have the flight controller board send wireless data to our LPC2148 board. With that data, we would perform data logging functions as well as forward the data to the GUI on our PC. Unfortunately, we were only able to forward the data to a terminal with this configuration. However, we were successful in interfacing the flight controller board with the GUI over Xbee directly. As such, this section will provide design and implementation details for both separate functions.

== Flight Controller Board ==

Our flight controller board is capable of sending data in different formats for different devices (arduino, bluetooth, or raw data for the GUI). We are using the full stream of raw data that is compatible with the GUI software we want to utilize. In the flight controller's main loop, it waits for certain 'op codes' to send back appropriately formatted data. This process is interrupt driven and sends data over UART. In this case, our op code of interest is 'M'. This causes the following steps to be performed until completion.

[[File:Cmpe146_S12_T4_FC_FlowChart.jpg|700px|thumb|center|alt=Flight Controller|Naze32 FunFly Flight Controller]]

== LPC2148 Board and GUI Interface ==

Our board used only one task. We chose to modify the already existant userInterface task given in our lab because it already uses interrupts and is setup to use UART0. We had to write a driver for UART1 in order to receive data from the flight controller board (using Xbee). Once received, we had to parse the data into appropriate sized containers and then forward that to a terminal or SD card. We also interfaced the board directly through UART to the GUI software we were using. This was as simple as creating a wireless UART bridge between the flight controller board and our PC. Once done, we used the GUI to open a serial connection and adjusted the polling frequency to take into account delays in wireless data transmission.

[[File:Cmpe146_S12_T4_Task_FlowChart.jpg|700px|thumb|center|alt=Task Flow Chart|Task Flow Chart]]

=== Testing & Technical Challenges ===

After obtaining a quadcopter block diagram, it was time to buy and assemble parts. This step was fairly smooth. Figuring out how to assemble the motors was a bit of a jigsaw puzzle but since there's a huge amount of variation in assembly required for such motors, it's hard to document.

Mounting the flight controller is also a bit tricky, depending on the frame you have the separation of holes on the flight control board. The Naze32 is a tiny board, measuring 1.5x1.5 inches so the holes were too close together. We opted to use double sided tape and stick it directly on the board using Velcro so that the board can be easily removed. This produces vibrations but we will have to wait for a flight test for confirmation.

Soldering the bullet connectors was easy - melt solder directly into the bowl of the container (get helping hands to hold the connector since it will get very hot!) and just dip the stripped wire and wait. Be sure to not strip too much of the wire since you don't want wire sticking out that carry 20 amps of current. It will be a good idea to heat-shrink these connectors for maximum safety (and it looks much more professional). Take care to get the heat shrink over both ends of the male and female. While the heatshrink covers the entire female, the male only needs to be covered about halfway - depending on the type of bullet connectors.

After the entire copter is assembled, it is time to calibrate the transmitter with the motors and ESCs. Connect the ESC 3-pin wire directly to the receiver and turn on the transmitter. Make sure ESC and motor is powered. The exact procedure should be documented on the datasheet of the ESC you have. Our ESCs were flashed using Simon Kirby's [https://github.com/sim-/tgy sim-tgy] firmware. Instructions for calibration is provided in his github.

'''[http://www.youtube.com/watch?v=cwnTA0SRxks Initial Flight Test]'''

=== Conclusion ===

The process of building a quadrocopter was long, irritating, tiring but also fun and rewarding. The quadrocopter included some hardware that we have never seen or used before and getting them to work was a handful. A lot of lessons have been learned during the making of this project. This conclusion will include some guideline for future student to follow and learn from our mistakes.

'''Scheduling'''

The process of building a quadrocopter isn’t difficult but time consuming. Be sure to set up a schedule and follow it. The team should be aware of each member’s capability and distribute the workload accordingly. It is important to keep track of each member’s progress every week to keep the schedule up to date and also provide pressure and motivation to get things done. It is absolutely best to start working on the project in the beginning week of the assignment. Time is limited and you will want as much time as possible. That way when obstacles are encountered and accidents happen, there is enough time to respond accordingly and fix them.

'''Back-Up Parts'''

Without proper planning and handling, this project could be a nightmare. One problem that occurred was not having replacement parts at hand. There were several scenarios where a piece of hardware became defective and the extra parts were needed. For example, a few days prior to demo, it was discovered that one of the electronic speed controllers needed to be replaced. However, all four ESCs need to be exactly the same, and the ESCs were bought online and took 2-3 days to ship. As a result, 4 new lower-quality ESCs had to be bought from a local store, and more money was spent. If we had extra ESCs to begin with, this situation could have been avoided altogether. As said before, with any project accidents should be expected (especially with doing something for the first time) and having extra parts will save you a lot of downtime. When ordering parts, be sure to order one or two extras.

'''Communication'''

Communication is always important in teamwork. Always keep your group mates up to date on your work because that allows a team to progress forward. It is important to ask for help when needed and offer help when possible. For our quadrocopter, asking experts for help was also very useful. An employee of California Hobbies (a store that was frequently visited for parts) was a great reference for information and helped us understand the communication between the RC transmitter, receiver, and Naze32 flight controller board. Since our quadrocopter is also being used for our senior design project, Dr. Donald Hung (our project advisor) was also able to help us establish a feasible goal and provide detail about any problems that might occur. Being backed by knowledgeable faculty and experts gave us confidence throughout the entire building process and is highly recommended for any Cmpe146 final project.

== References ==
=== Acknowledgement ===

[http://www.rcgroups.com/forums/member.php?u=340315 timecop @RCGroups] 
[http://www.rcgroups.com/forums/member.php?u=339839 simonk @RCGroups]

=== References Used ===

[http://www.endurance-rc.com/ppmtut.php PWM and PPM explained]

[http://electroniccircuitsforbeginners.blogspot.com/2011/05/quadrocopters-for-beginners.html Flight Mechanics information]

[http://www.multiwii.com/ Information related to MultiWii GUI]

=== Appendix ===
You can list the references you used.
Attach your zipped code here that may be used by other people in the future.

[http://www.socialledge.com/sjsu/index.php?title=File:Qcopter.zip Code]

File:Cmpe146 s12 t4 copter.jpg

2012-05-25T19:08:42Z

146S12T4:

File:Qcopter.zip

2012-05-25T18:54:05Z

146S12T4: The quadcopter eclipse project - contains information on getting the Xbee working and interfacing with the computer over UART.

The quadcopter eclipse project - contains information on getting the Xbee working and interfacing with the computer over UART.

File:Cmp146 s12 t4 wiringharness.JPG

2012-05-25T18:48:51Z

146S12T4:

File:Cmpe146 s12 t4 escconections.jpg

2012-05-25T18:43:02Z

146S12T4:

File:Cmp146 s12 t4 fc con.jpg

2012-05-25T18:42:36Z

File:Cmpe146 s12 t4 frame.JPG

2012-05-23T19:56:00Z

146S12T4: The quadcopter frame used in the build. It's an all aluminum frame that is made by Chinese manufacturer HobbyLord and distributed via online channels such as www.hobbycool.com

The quadcopter frame used in the build. It's an all aluminum frame that is made by Chinese manufacturer HobbyLord and distributed via online channels such as www.hobbycool.com

File:Cmpe146 s12 t4 fc.jpg

2012-05-23T19:52:14Z

146S12T4: The Afroflight FunFly Naze32 Flight Controller distributed by timecop via his website at www.abusemark.com

The Afroflight FunFly Naze32 Flight Controller distributed by timecop via his website at www.abusemark.com

File:Cmpe146 s12 t4 esc.jpg

2012-05-23T19:50:43Z

146S12T4: DYS 30A ESC. Flashed with Simon Kirby's custom firmware for better response and handling. Also bought from Ken's Quadroufo store

DYS 30A ESC. Flashed with Simon Kirby's custom firmware for better response and handling. Also bought from Ken's Quadroufo store