Revision as of 02:16, 22 December 2014 (view source) Proj user8 (talk | contribs) (→‎Communication Bridge + Android #3) ← Older edit		Revision as of 02:19, 22 December 2014 (view source) Proj user8 (talk | contribs) (→‎I/O Team Issues) Newer edit →
Line 2,358:		Line 2,358:
	'''PROBLEM:'''		'''PROBLEM:'''
−	Tasks blocking each other, thus slowing down performance	+	Architecture which used a mutex to share UART lines between tasks was causing the button on the LCD display to not be very reliable.
	'''RESOLUTION:'''		'''RESOLUTION:'''
−	Restructured task architecture	+	Instead of using a mutex, different priorities were used instead. The higher priority task will have complete control over the UART until it is done, however the higher priority task will only be active when there are user interactions with the LCD display.
	'''FUTURE RECOMMENDATIONS:'''		'''FUTURE RECOMMENDATIONS:'''
−	Draw out architecture first, then code	+	Architectural design should be considered and planned out fully before coding.
	==== I/O Team Issue #2 ====		==== I/O Team Issue #2 ====
	'''PROBLEM:'''		'''PROBLEM:'''
		+
		+	More performance enhancements needed to boost refresh rate for the LCD display. The display shows many different information (sensor values, motor information, etc.).
	'''RESOLUTION:'''		'''RESOLUTION:'''
		+
		+	Based on which form is activated on the screen (Sensor Form, Motor Form, etc.), the software would discard and not process information for other forms that do not need to be updated currently (with exception for Bridge).
	'''FUTURE RECOMMENDATIONS:'''		'''FUTURE RECOMMENDATIONS:'''
−		+
		+	Find areas for optimizations to better improve performance. If analyzed closer, there could be other areas which could improve performance, but the screen seemed sufficiently responsive now.
		+
	=== Communication Bridge + Android Team Issues ===		=== Communication Bridge + Android Team Issues ===

---

Revision as of 02:19, 22 December 2014

Grading Criteria

• How well is Software & Hardware Design described?
• How well can this report be used to reproduce this project?
• Code Quality
• Overall Report Quality:
  • Software Block Diagrams
  • Hardware Block Diagrams

    Schematic Quality

  • Quality of technical challenges and solutions adopted.

Chi Lam

In Memory of Chi Lam

June 7th, 1991 - October 27th, 2014



This project is dedicated to Chi Lam, a beloved friend, dedicated Computer Engineering student, and member of this team.

You will be missed, friend

Self-Driving Autonomous Car

Abstract

The objective of the project is to create a self-driving autonomous car in a 15 person team. The car utilizes several components and sensors in order to get from Point A to Point B. Implementation of the car involves multiple SJONE processor boards using FreeRTOS to communicate with each other via CAN bus.

Objectives & Introduction

Show list of your objectives. This section includes the high level details of your project. You can write about the various sensors or peripherals you used to get your project completed.

Team Members & Responsibilities

The team consisted of 15 undergraduate students taking a graduate level course, thus competing against the Master's level students.

We are

Master Controller Team
Charles Pham	Joshua Ambion	Michael Schneider
- Overall vehicle logic - Overall software vehicle Integration - CAN TX/RX messages architecture	- Vehicle hardware interfacing - Assistant to other teams - Module specific logic	- Module specific logic - CAN RX processing

Motor Controller Team
Nikko Esplana	Chi Lam
- Motor/steering control via PWM signals - interface/test/attach wheel encoder	- Rest in peace Chi!

Sensor Controller Team
Sanjay Maharaj	Wei-chieh "Andy" Lo
- Vehicle hardware - Sensor implementation - CAN communication	- Sensor implementation - Sensor values verification - CAN communication

Geographical Controller Team
Carlos Fernandez-Martinez	Zach Baumgartner	Albert Chen
- Compass calibration/integration & structure modelling	- GPS testing/integration & structure modelling	- CAN communication

Bridge Controller Team
Robert Julius	Tim Martin	Joseph Bourne
- Android Application	- Bluetooth Message Interface	- Board to CAN Communication

IO Controller Team
Devin Villarosa	George Sebastian
- Receive Task - GUI Interface - Headlights Task - uLCD Library	- Event Handle Task - GUI Interface - Headlights Task - uLCD Library

Schedule

Final Product Schedule

Week#	Date	Task	Actual
1	10/12	CAN Network Benchtest	Complete
2	10/15	Basic CAN Communication	Complete
3	10/31	Secure devices to R/C car	Complete
4	11/7	Basic Vehicle Self-Driving Test	In progress
5	11/14	P2P testing and improved obstacle avoidance	In progress
6	11/31	Buffer time for previous tasks and increased vehicle speed	In progress

Sensor Controller Schedule

Week#	Date	Task	Actual
1	10/13	Sensor Input Distance Calibration	Incomplete: Sonar is mostly calibrated, IR still needs work. Need sensor value "filtering" logic.
2	10/17	Off car CAN network test (full team)	Completed. Able to send raw sensor value to master.
3	10/20	Interface Sensors with CAN	Completed. Updates to the formatting of data being sent is ongoing.
4	10/27	Mount Sensors and test coverage	Completed. Still need to mount with actual brackets.
5	10/31	Mount Sensors with 3d printed brackets	Completed. IR brackets to be printed based on offset.
6	11/1	Implement diagnostic LED patterns	Completed.
7	11/3	Send obstacle avoidance decisions to master	Completed. Raw values sent to master for processing.
8	11/4	Add RJ11 cabling to all sensors	Completed. Still need to make neat and tidy.
9	11/10	Eliminate outliers (software)	Completed.
10	11/13	Eliminate outliers by strengthening sensor wiring (hardware)	Completed.
12	11/24	Continue testing and tuning as necessary	In progress

Motor Controller Schedule

Week#	Date	Task	Actual
1	10/12	Open up servo and motor modules, find a speed sensor	Complete
2	10/19	Interface/test PWM bus to steering servo and DC motor	Complete
3	10/26	Allow self-driving capability with master/bridge/sensor teams	Incomplete, only partial self-driving achieved
4	11/2	Improve fine motor movements with master/sensor teams	Incomplete, still needs tweaking.
5	11/9	Once wheel encoder comes in, learn/test/implement onto car	Incomplete, wheel encoder cannot be implemented, scrapping.
6	11/16	Integrate wheel encoder with rest of car	Incomplete, scrapped wheel encoder.
7	11/23	Test for proper operation	Complete, added functionality for center steer and forward speed calibration.
8	11/30	Continue testing until proper operation	Complete, motor works as intended.

I/O Schedule

Week#	Date	Task	Actual
1	10/4	Create LCD Screen Library (create ability to set value, get value, and write string to LCD screen)	10/4 (String function completed on ~10/18)
2	10/4	Create LCD Screen GUI (generate forms for debugging and general usage)	10/4
3	10/11	LCD Library Test (Do unit tests on individual functions for LCD library) Ability to get value from gauge on screen. Ability to set value to gauge on screen. Ability to send a string value to screen.	10/11 (Finished string function on ~10/18)
4	10/11	Interface LCD with CAN Create task for LCD event loop. Create task for Receiving on CAN.	Complete (Completed on 10/26/2014)
5	10/18	Test LCD with CAN Process CAN Messages from system	Complete (Completed on 10/25/2014)
6	10/25	Implement onto Final Product	Complete (Completed on 11/23/2014)
7	11/2	Headlights for car (hardware and software) + Aesthetics for GUI + Clean up code	Complete (Completed on 12/01/2014) *NOTE Headlights are lost in hardware land

Communication Bridge and Android Schedule

Week#	Date	Task	Actual
1	10/13	CAN Network Test	Complete
2	10/20	Interface Bluetooth Module with CAN	Complete
3	10/27	Mount PCB on car	In progress
4	11/3	Create basic Android application	Completed on 10/18
5	11/10	Add map onto the Android application	In Progress
6	11/17	Send/receive CAN Messages via Android Application	Sending completed on 10/18, receiving in progress
7	11/24	Debug and Optimize Android Application	In progress
8	12/1	Continue Debugging and Optimizing as Necessary	In progress

Geographical Controller Schedule

Week#	Date	Task	Actual
1	10/8	Interface with GPS/Compass	Complete - receiving values
2	10/15	Finish core API	Complete
3	10/22	GPS get fix and receive raw data	Complete - raw data received, but need faster fix
4	10/22	Compass determine heading	Complete - heading may require additional calibration
5	10/29	Self calibration completed	Complete
6	10/29	GPS parse raw data to extract needed data	Complete - returns latitude, longitude, and calculated heading
7	10/29	Compass use heading from GPS to improve accuracy	In progress - may not provide tangible improvement
8	11/5	Improve GPS satellite procurement (antennae?)	Complete - attached antennae to GPS unit
9	11/12	Improve boot up time of GPS module via warm start	N/A - EZ start fast fix mode cannot coincide with 10 Hz update rate (defaults down to 1 Hz)
10	11/12	Fine tune compass calibration technique for accuracy	Complete - Compass still about 10 degrees off, but well within usable margins. Offset likely due to nearby power source on car.
11	12/3	Buffer time for completion of previous tasks	Complete

Master Controller Schedule

Line Item #	Expected End Date	Task	Status
1	10/15/14	Decide on raw CAN struct architecture	Early completion
2	10/18/14	Develop and layout general common CAN messages	On-time completion
3	10/20/14	Design vehicle initialization procedure	Early completion
4	10/23/14	Develop and layout Inter-Controller Communication - Each Module's CAN messages	Early completion
5	10/25/14	Design vehicle initial running freed drive mode procedure - Controlled via Phone, no object detection and avoidance, no GPS, no Heading	Early completion
6	10/28/14	Complete design on vehicle running free drive mode procedure	On-time completion
7	10/30/14	Design vehicle initial running indoor drive mode procedure - Timed autonomous drive , object detection and avoidance, (possibly heading), and no GPS	In progress
8	11/01/14	All CAN message definitions complete	Early Completion
9	11/02/14	Design vehicle initial running gps drive mode procedure - Full autonomous drive , object detection and avoidance, heading and GPS	In progress
10	11/05/14	All CAN message receive processing complete	On-time completion
11	11/14/14	All basic vehicle functionality state machines implemented and verified	On-time completion
12	11/15/14	Complete design on vehicle running indoor drive mode procedure	In progress
13	11/20/14	Complete design on vehicle running gps drive mode procedure	In progress
14	11/30/14	Any additional advanced functionality implemented and verified	In progress

Parts List & Cost

Line Item#	Part Desciption	Vendor	Part Number	Qty	Cost ($)
1	CAN Board	Waveshare International Limited	SN65HVD230	15	92.00
2	Traxxas Slash Pro 2WD Short-Course R/C Truck	Traxxas	58034 Slash	1	337.00
3	Adafruit Ultimate GPS Breakout	Adafruit	MTK3339	1	39.95 + (4.685 Shipping)
4	Triple-axis Accelerometer+Magnetometer (Compass) Board	Adafruit	LSM303	1	14.95 + (4.685 Shipping)
5	GPS Antenna - External Active Antenna - 3-5V 28dB 5 Meter SMA	Adafruit	960	1	12.95 + (4.735 Shipping)
6	SMA to uFL/u.FL/IPX/IPEX RF Adapter Cable	Adafruit	851	1	3.95 + (4.735 Shipping)
7	3.5" Intelligent module w/ Touch	4D Systems	uLCD 35DT	1	89.00
8	2GB microSD Card
9	uUSB-PA5 Programming Adaptor
10	150mm 5 way Female-Female jumper cable
11	5 way Male-Male adaptor
12	Sharp Infrared Range Finder	4D Systems	GP2Y0A21	2	9.95 + 3.32 Shipping
13	SainSmart Sonar Ranging Detector	Amazon	HC-SR04	3	5.59
14	RC LED Headlights	Amazon Prime		2	5.99
15	XBee Bluetooth	Amazon Prime	WLS04051P	1	27.50
16	SJONE Board	Preet Industries		6	480.00
17	Traxxas XL5 ESC unit	dollarhobbyz.com	2WDS ESC	2	54.00 + (4.67 Shipping)
	Additional Shipping				$$$.$$
	Total Cost				$$$.$$

Design & Implementation

The design section can go over your hardware and software design. Organize this section using sub-sections that go over your design and implementation.

Hardware Design

Overall Hardware Design Components

58034 Traxxas Slash RC Truck: Traxxas Slash Pro 2WD Short-Course Truck: Came with TQ 2.4GHz radio transceiver + remote control, 8.4V/3000mAh Ni-MH Power 7-Cell Battery, and wall charger. Optional purchase: 7.4V/5800mAh Li-Po battery for longer operation.	Traxxas Slash Pro 2WD Short-Course Truck
SN65HVD230 CAN Board Transceiver: INSERT DESCRIPTION HERE The SN65HVD230 CAN board transceiver is used to interface the microcontrollers logical signals to CAN electrical specifications. The SN65HVD230 CAN board transceiver was chosen specifically because not only did it work perfectly for CAN interfacing, but it came pre-built with the in-line resistors. Because there were fifteen people in our team, this was desired because a lot of work would be needed if we built each CAN board transceiver individually. The transceivers were purchased on eBay for $8.99 each. However, the item's location was in China, so ordering early would be best for future students.	SN65HVD230 CAN Board Transceiver
3D Printed Materials: The chassis of the remote control car does not offer many points of attachment for hardware and other peripheral devices. Therefore, additional structures needed to be designed to accommodate for the various boards, sensors, and accessories. To design these structures, Autodesk Inventor 2014 and SolidWorks 2013 were used. These CAD applications allow a 3-D model of an object to created and then exported as a file capable of printing the model on a 3-D printer. For the 3-D printer, we used a MakerBot Replicator 2. This printer takes a .stl file from the CAD software and converts it to a printable model using MakerBot MakerWare. Then, the model is printed by layering thin layers of ABS plastic. The first structure that was built was the main platform. This platform acted as a mount for the six SJOne boards and the six CAN transceivers. Then, several structures needed to be created to mount the ultrasonic and sonar sensors at the front and back of the vehicle. Next, the LCD required a mount so it could float freely on the car and be both usable and sturdy, in case of a crash. Finally, a tower was designed to keep the antennae high and away from other components, like the magnometer. This is because the antennae has a huge magnet on the bottom for mounting purposes and was interfering with the compass readings. The models of the different structures can be seen in this section.

Sensor Controller Team Hardware Design

Sensor Pin Connections

Line Item#	Node A Source	Node A Pin	Node B Source	Node B Pin	Description
1	3.3V Power Supply	3.3V	SJOne Board	3V3	SJOne Power
2	3.3V Power Supply	GND	SJOne Board	GND	SJOne Ground
3	CAN Transceiver	Tx	SJOne Board	P0.1 (Tx)	SJOne - CAN Tx
4	CAN Transceiver	Rx	SJOne Board	P0.0 (Rx)	SJOne - CAN Rx
5	CAN Transceiver	3.3V	3.3V Power Supply	3.3V	SJOne - CAN Power
6	CAN Transceiver	Ground	3.3V Power Supply	GND	SJOne - CAN Ground
7	HC-SR04 Ultrasonic Sensor (Front Left)	Vcc	5V Power Supply	+5V	Front Left Sensor Power
8	HC-SR04 Ultrasonic Sensor (Front Left)	GND	5V Power Supply	GND	Front Left Sensor GND
9	HC-SR04 Ultrasonic Sensor (Front Left)	Echo	SJOne Board	P2.0	Front Left Sensor Echo
10	HC-SR04 Ultrasonic Sensor (Front Left)	Trig	SJOne Board	P2.1	Front Left Sensor Trig
11	HC-SR04 Ultrasonic Sensor (Front Right)	Vcc	5V Power Supply	+5V	Front Right Sensor Power
12	HC-SR04 Ultrasonic Sensor (Front Right)	GND	5V Power Supply	GND	Front Right Sensor GND
13	HC-SR04 Ultrasonic Sensor (Front Right)	Echo	SJOne Board	P2.2	Front Right Sensor Echo
14	HC-SR04 Ultrasonic Sensor (Front Right)	Trig	SJOne Board	P2.3	Front Right Sensor Trig
15	LV-MaxSonar-EZ-0 Ultrasonic Range Sensor (Front Middle)	Vcc	5V Power Supply	+5V	Front Middle Sensor Power
16	LV-MaxSonar-EZ-0 Ultrasonic Range Sensor (Front Middle)	GND	5V Power Supply	GND	Front Middle Sensor GND
17	LV-MaxSonar-EZ-0 Ultrasonic Range Sensor (Front Middle)	Echo	SJOne Board	P2.4	Front Middle Sensor Echo
18	LV-MaxSonar-EZ-0 Ultrasonic Range Sensor (Front Middle)	Trig	SJOne Board	P2.5	Front Middle Sensor Trig
19	HC-SR04 Ultrasonic Sensor (Rear Left)	Vcc	5V Power Supply	+5V	Rear Left Sensor Power
20	HC-SR04 Ultrasonic Sensor (Rear Left)	GND	5V Power Supply	GND	Rear Left Sensor GND
21	HC-SR04 Ultrasonic Sensor (Rear Left)	Echo	SJOne Board	P2.6	Rear Left Sensor Echo
22	HC-SR04 Ultrasonic Sensor (Rear Left)	Trig	SJOne Board	P2.7	Rear Left Sensor Trig
23	HC-SR04 Ultrasonic Sensor (Rear Right)	Vcc	5V Power Supply	+5V	Rear Right Sensor Power
24	HC-SR04 Ultrasonic Sensor (Rear Right)	GND	5V Power Supply	GND	Rear Right Sensor GND
25	HC-SR04 Ultrasonic Sensor (Rear Right)	Echo	SJOne Board	P2.8	Rear Right Sensor Echo
26	HC-SR04 Ultrasonic Sensor (Rear Right)	Trig	SJOne Board	P2.9	Rear Right Sensor Trig
27	CAN Transceiver	CANL	CAN BUS	CANL	CANL to CAN BUS
28	CAN Transceiver	CANR	CAN BUS	CANR	CANR to CAN BUS

Sensor Controller Hardware Design Components

Method of Operation
1. INPUT: The sensor is triggered by a 10uS pulse HIGH on the trig pin.
2. RANGING: The sensor sends out eight 40kHz sonar pulses.
3. OUTPUT: The sensor outputs a pulse HIGH with the pulse time depending on the distance of the object on the echo pin.

The the output from the echo pin can be seen below, as captured by an oscilloscope.


While the HC-SR04 is an affordable way to implement distance ranging ability, there are some points to be aware of prior to implementation:
1. The sonar frequency is approximately 40kHz. Using multiple sonar sensors to detect the same object could lead to erroneous data due to interference.
2. As distance increases, so does noise. The reliable range of values in our case were between 3cm and 70 cm. Any other values were filtered out in software.

HC-SR04 Ultrasonic Distance Sensor: The HC-SR04 is a distance sensor which detects objects using ultrasonic signals. The sensor is capable of detecting distances within 2cm-500cm. The sensor runs off 5V DC. Four pins are used: Vcc, Ground, Trig, and Echo. These sensors are relatively inexpensive, so four sensors were purchased. The four HC-SR04 sensors were implemented on our car at the following locations: front-left, front-right, rear-left, and rear-right.

HC-SR04 Ultrasonic Sensor

LV-MaxSonar-EZ0 Ultrasonic Range Sensor: The LV-MaxSonar-EZ0 is a high sensitivity and wide beam ultrasonic range sensor. The sensor is capable of reading objects at a maximum range of 645cm. The sensor is more expensive is, therefore, a lot stronger than the HC-SR04 sensors. Because the sensor's capabilities, it was used as the front-center sensor.

LV-MaxSonar-EZ0 Ultrasonic Range Sensor

Motor Controller Team Hardware Design

As seen above, the car battery(accepts compatible Ni-MH, Li-Po, and Ni-Cad batteries) powers the ESC unit (XL-5), which in turn drives the Titan 12T-550 motor and also powers the steering servo. It is necessary for the ESC unit, steering servo and SJ One board to share a common ground in order for the PWM signals to have the same reference voltage.

The CAN transceiver requires the use of the SJ One Board's +3.3V and GND, as well as P0.0 (CAN RX) and P0.1 (CAN TX).

P2.0/P2.1 (PWM1/PWM2) controls the steering/motor via the SJ One board by sending out PWM signals that change the width of a 20ms period waveform. 1ms width represents a 0% duty cycle, 1.5ms width represents a 50% duty cycle, and 2ms width represents a 100% duty cycle.

Controlling motor and steering

In the photo above, a digital oscilloscope probes a PWM pin on the SJ One board and detects a signal with a 3.3 peak-to-peak voltage, a 100hz PWM frequency, and a width of 1.5ms (50% duty cycle). In terms of steering control, a width between 1ms to 1.499ms equates to left steering (1ms = max left angle) and a width between 1.501ms to 2ms equates to right steering (2ms = max right angle). The motor is similar, such that a width between 1ms to 1.499ms equates to a reverse throttle and a width between 1.501ms to 2ms equates to a forward throttle. For both steering and motor control, 1.5ms (50% duty cycle) represents a center steer or non-throttle.

Motor Controller Hardware Design Components

58034 Traxxas Slash RC Truck: Traxxas Slash Pro 2WD Short-Course Truck: Came with TQ 2.4GHz radio transceiver + remote control, 8.4V/3000mAh Ni-MH Power 7-Cell Battery, and wall charger. Optional purchase: 7.4V/5800mAh Li-Po battery for longer operation.	Traxxas Slash Pro 2WD Short-Course Truck
Traxxas XL-5 Electronic Speed Control (ESC) Unit: Waterproof ESC unit, it directly controls the movement of the Titan 12T 550. It is powered by the car battery and shares a common ground between the steering servo and SJ One board. The ESC controls the throttle of the motor via PWM signals being sent from the SJ One board, which is then sent as a positive or negative voltage to drive the motor.	Traxxas XL-5 Electronic Speed Control (ESC) Unit
Steering Servo: Powered by the ESC unit and shares a common ground between the ESC unit and SJ One board. It is controlled via PWM signals sent from the SJ One board and regulates the angle of the front wheels.	Steering Servo

Motor Pin Connections

Line Item#	Node A Source	Node A Pin	Node B Source	Node B Pin	Description
1	3.3V Power Supply	3.3V	SJOne Board	3V3	SJOne Power
2	3.3V Power Supply	GND	SJOne Board	GND	SJOne Ground
3	CAN Transceiver	CAN Tx	SJOne Board	P0.1 (Tx)	SJOne - CAN Tx
4	CAN Transceiver	CAN Rx	SJOne Board	P0.0 (Rx)	SJOne - CAN Rx
5	CAN Transceiver	3.3V	3.3V Power Supply	3.3V	SJOne - CAN Power
6	CAN Transceiver	Ground	3.3V Power Supply	GND	SJOne - CAN Ground
7	CAN Transceiver	CANL	CAN BUS	CANL	CANL to CAN BUS
8	CAN Transceiver	CANR	CAN BUS	CANR	CANR to CAN BUS
9	Steering Servo	PWM Port	SJOne Board	P2.0 PWM	Steering Control
10	Steering Servo	Ground	SJOne Board	GND	Common ground for reference voltage
11	ESC/Motor	PWM Port	SJOne Board	P2.1 PWM	Motor Control
12	ESC/Motor	Ground	SJOne Board	GND	Common ground for reference voltage

I/O Team Hardware Design

I/O Design Components

uLCD-35DT Intelligent Display Module: INSERT DESCRIPTION HERE The uLCD-35DT is an intelligent display module used to display information of the system, such as viewing the GPS destination, and a controller for the system, such as setting the car to indoor mode which tests for sensor only navigation. The uLCD-35DT system was chosen specifically because of its touch screen capabilities. The display is driven by A DIABLO16 processor. The processor allows stand-alone functionality for the screen. In order to program the screen with an interactive GUI, the 4D Systems Workshop 4 IDE Software was used.

I/O Pin Connections

Line Item#	Node A Source	Node A Pin	Node B Source	Node B Pin	Description
1	LCD	1 (LCD +5V)	5V Power Supply	5V	uLCD 35DT LCD Power
2	LCD	7 (LCD GND)	5V Power Supply	GND	uLCD 35DT LCD Ground
3	LCD	5 (LCD RX)	SJOne Board	RX3	uLCD 35DT LCD Receive Pin
4	LCD	3 (LCD TX)	SJOne Board	TX3	uLCD 35DT LCD Transmit Pin
5	3.3V Power Supply	+3.3V	SJOne Board	3V3	SJOne Power
6	3.3V Power Supply	GND	SJOne Board	GND	SJOne Ground
7	UART2 RX	P2.9	SJOne RX
8	UART2 TX	P2.8	SJOne TX
9	+5V	+5V Power	SJOne Board	GPIO P2.0	Active Low
10	+5V	+5V Power	SJOne Board	GPIO P2.1	Active Low
11	+5V	+5V Power	SJOne Board	GPIO P2.2	Active Low
12	+5V	+5V Power	SJOne Board	GPIO P2.3	Active Low
13	CAN Transceiver	CAN Tx	SJOne Board	P0.1 (Tx)	SJOne - CAN Tx
14	CAN Transceiver	CAN Rx	SJOne Board	P0.0 (Rx)	SJOne - CAN Rx
15	CAN Transceiver	CAN 3.3V	3.3V Power Supply	3.3V	SJOne - CAN Power
16	CAN Transceiver	CAN Ground	3.3V Power Supply	GND	SJOne - CAN Ground
17	CAN Transceiver	CANL	CAN BUS	CANL	CANL to CAN BUS
18	CAN Transceiver	CANR	CAN BUS	CANR	CANR to CAN BUS

Communication Bridge + Android Hardware Design

The Bluetooth module is connected to the SJOne board through the XBee socket, with only the RX/TX data connections into the board.

Communication Bridge Pin Connections

Line Item#	Node A Source	Node A Pin	Node B Source	Node B Pin	Description
1	3.3V Power Supply	3.3V	SJOne Board	3V3	SJOne Power
2	3.3V Power Supply	GND	SJOne Board	GND	SJOne Ground
3	CAN Transceiver	CAN Tx	SJOne Board	P0.1 (Tx)	SJOne - CAN Tx
4	CAN Transceiver	CAN Rx	SJOne Board	P0.0 (Rx)	SJOne - CAN Rx
5	CAN Transceiver	CAN 3.3V	3.3V Power Supply	3.3V	SJOne - CAN Power
6	CAN Transceiver	CAN Ground	3.3V Power Supply	GND	SJOne - CAN Ground
7	Bluetooth Bee	VCC	3.3V Power Supply	3V3	Bluetooth Bee Power
8	Bluetooth Bee	GND	3.3V Power Supply	GND	Bluetooth Bee GND
9	Bluetooth Bee	RX	SJOne Board	P2.9 (RXD2)	Bluetooth Bee RX
10	Bluetooth Bee	TX	SJOne Board	P2.8 (TXD2)	Bluetooth Bee TX
11	CAN Transceiver	CANL	CAN BUS	CANL	CANL to CAN BUS
12	CAN Transceiver	CANR	CAN BUS	CANR	CANR to CAN BUS

Communication Bridge + Android Hardware Design Components

Bluetooth Bee Standalone: The Bluetooth Bee Standalone Module by Seeed Studio Works allows for the connection of a bluetooth module onto the XBee Socket of the SJOne Board. This module contains an ATMEGA168 for reprogramming. Only the SJOne Board's UART2/3 pins are capable of transferring data to the module, depending on which UART the XBee Socket is connected to with a switch configuration. When the module receives the command to enter pairing mode (by sending the message "\r\n+INQ=1\r\n" through UART), the red and blue LEDs will alternate flashing light. Once the module has been paired, then the bluetooth module's blue LED will flash once per two seconds. Otherwise, the blue LED will flash twice per second. This module was chosen for its XBee Socket compatibility.

Geographical Controller Team Hardware Design

Geographical Pin Connections

Line Item#	Node A Source	Node A Pin	Node B Source	Node B Pin	Description
1	3.3V Power Supply	3.3V	SJOne Board	3V3	SJOne Power
2	3.3V Power Supply	GND	SJOne Board	GND	SJOne Ground
3	CAN Transceiver	Tx	SJOne Board	P0.1 (Tx)	SJOne - CAN Tx
4	CAN Transceiver	Rx	SJOne Board	P0.0 (Rx)	SJOne - CAN Rx
5	CAN Transceiver	3.3V	3.3V Power Supply	3.3V	SJOne - CAN Power
6	CAN Transceiver	Ground	3.3V Power Supply	GND	SJOne - CAN Ground
7	MTK3339 GPS	VCC	5V Power Supply	+5V	MTK3339 GPS Power
8	MTK3339 GPS	GND	5V Power Supply	GND	MTK3339 GPS GND
9	MTK3339 GPS	RX	SJOne Board	RXD2	MTK3339 GPS RX
10	MTK3339 GPS	TX	SJOne Board	TXD2	MTK3339 GPS TX
7	LSM303 Compass + Accelerometer	VIN	5V Power Supply	+5V	Compass + Accelerometer Power
8	LSM303 Compass + Accelerometer	GND	5V Power Supply	GND	Compass + Accelerometer GND
9	LSM303 Compass + Accelerometer	RX	SJOne Board	RXD2	Compass + Accelerometer SCL
10	LSM303 Compass + Accelerometer	TX	SJOne Board	TXD2	Compass + Accelerometer SDA
11	CAN Transceiver	CANL	CAN BUS	CANL	CANL to CAN BUS
12	CAN Transceiver	CANR	CAN BUS	CANR	CANR to CAN BUS

Geographical Controller Hardware Design Components

Adafruit MTK3339 GPS: INSERT DESCRIPTION HERE
Adafruit LSM303 Compass: The device provides access to both a Compass and 3-Axis accelerometer. The device is interfaced via I2C. By using the a Compass with an Accelerometer, it is possible to do tilt compensation, for increased accuracy. In the team's current design, however this feature was not used.

Master Controller Team Hardware Design

Master Pin Connections

Line Item#	Node A Source	Node A Pin	Node B Source	Node B Pin	Description
1	3.3V Power Supply	3.3V	SJOne Board	3V3	SJOne Power
2	3.3V Power Supply	GND	SJOne Board	GND	SJOne Ground
3	CAN Transceiver	CAN Tx	SJOne Board	P0.1 (Tx)	SJOne - CAN Tx
4	CAN Transceiver	CAN Rx	SJOne Board	P0.0 (Rx)	SJOne - CAN Rx
5	CAN Transceiver	CAN 3.3V	3.3V Power Supply	3.3V	SJOne - CAN Power
6	CAN Transceiver	CAN Ground	3.3V Power Supply	GND	SJOne - CAN Ground
7	CAN Transceiver	CANL	CAN BUS	CANL	CANL to CAN BUS
8	CAN Transceiver	CANR	CAN BUS	CANR	CANR to CAN BUS

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.

SYSTEM LEVEL HARDWARE INTERFACE INTERFACE GOES HERE

Sensor Controller Team Hardware Interface

Sensor team uses CAN bus as a communication bus to communicate with master. The specific message ID used is 0x330. There are 5 sensor values (Front Left, Front, Front Right, Rear Left, Rear Right). 8 bits of integer is the size of our data for each sensor. frontLeftDistance:uint8_t:bytes[0] frontDistance:uint8_t:bytes[1] frontRightDistance:uint8_t:bytes[2] rearLeftDistance:uint8_t:bytes[3] rearDistance:uint8_t:bytes[4] rearRightDistance:uint8_t:bytes[5] After microcontroller obtained all the values, a tasks that is designated to send data to master will run. Every sensor value is updated periodically.

Motor Controller Team Hardware Interface

The motor team only uses the CAN bus for simple communication. Only 2 messages are being listened for: 0x100 and 0x124.

 -0x100 is the master heartbeat message and motor replies back with message 0x200 for acknowledgement.

 -0x124 is the master movement command message. Master sends a uint8_t byte, with unique numbers that 
  represent specific movement commands such as forward, reverse, left forward, right reverse, etc.

During each heartbeat, a second message is sent: 0x221

 -0x221 contains 2 dwords, as it sends two float values (reinterpreted to uint32_t) to I/O. dword[0] 
  is a float type containing the forward speed value and dword[1] is also a float type containing the 
  neutral steer value.

PWM signals are sent from the SJ One board towards the ESC unit and steering servo. Depending on the width of the signals sent (ranging between 1ms to 2ms), the motor and steering can be manipulated.

I/O Team Hardware Interface

Communication Bridge + Android Hardware Interface

    Discuss your hardware design of Communication Bridge and Android
    *SHOW HOW FRAMES ARE SENT

123

Geographical Controller Team Hardware Interface

    Discuss your hardware design of Geographical Controller
    *SHOW HOW FRAMES ARE SENT
    

Master Controller Team Hardware Interface

    Discuss your hardware design of Master Controller
    *SHOW HOW FRAMES ARE SENT

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.

SYSTEM LEVEL SOFTWARE DESIGN GOES HERE

Sensor Controller Team Software Design

    Describe how your hardware communicates. WHAT BUSes were used
    *SHOW SOFTWARE FLOWCHART DIAGRAM

Motor Controller Team Software Design

The Motor module only has one running task. That is to listen to two CAN messages from the Master module (0x100 and 0x124). During each heartbeat (0x100), Motor will send back an acknowledgement CAN message (0x200) and send the current forward speed value and neutral steer value with a CAN message (0x221) for the I/O module. When Motor receives (0x124) from Master, it will unpack that CAN message and execute the given movement command, which can be seen in the table below.

Motor Movement Commands

Master CAN Payload Value	Movement Command
0	No command
1	Slow forward
2	Fast forward
3	Slow reverse
4	Fast reverse
5	Slow right forward
6	Slow left forward
7	Slow right reverse
8	Slow left reverse
9	Stop

I/O Team Software Design

The I/O Software is based off of two tasks: The Event Handler Task and the RX Task.

Event Handler Task (High Priority):

This Task receives any immediate messages sent from the uLCD, processes the message, and sends the message to the CAN BUS.

This task enables the system to: Turn On/Off the Vehicle and Change Vehicle Modes.

RX Task (Low Priority):

This task receives all messages from the CAN BUS, and outputs message data onto the uLCD

High Level IO Software Logic

Event Handler Task Logic

RX Task Logic

Communication Bridge + Android Software Design

    Discuss your hardware design of Communication Bridge and Android
    *SHOW SOFTWARE FLOWCHART DIAGRAM

Geographical Controller Team Software Design

Master Controller Team Software Design

The master controller has a single receive task that fans out the messages into individual "modules". The modules then either store the data from the incoming messages into the module's variables, or call the vehicle logic API functions to alter the state of the vehicle.

Each module includes a queue that stores messages until the module has the opportunity to process it. The module code then processes the received message, which can include updating the module's variables. Module variables include data such as the current GPS location. All modules are friends of the vehicle logic class, so the vehicle logic can access these variables to get their data.

Software Interface

This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.

SYSTEM LEVEL SOFTWARE IMPLEMENTATION GOES HERE

Sensor Controller Team Software Interface

 -can_comm.cpp Tasks that retrieve sensor values and send them to CAN bus.
 -main.cpp Calling all the tasks that are implemented in can_comm.cpp

Motor Controller Team Software Interface

The main function initializes the CAN bus and proceeds to call the only task called CAN_rx_tx.

 -CAN_rx_tx.hpp contains an object declaration for a task that receives and sends out CAN messages.
 -CAN_rx_tx.cpp contains instructions on what CAN message IDs to listen for and what to execute when 
  those messages are received.
 -motor_typedef.h contains nomenclature for values used within the program.

I/O Team Software Interface

    Describe steps to communicate hardware

Communication Bridge + Android Software Interface

    Describe steps to communicate hardware

Geographical Controller Team Software Interface

Master Controller Team Software Interface

The primarily interaction between software level and hardware level was done over the CAN interface.

CAN Communication Table

Master CAN Communication Table

TX Message ID	TX Message Transmit Rate	TX Message Description	RX Response Message ID	RX Listening Module
0x100	1hz Periodic	Request Heartbeat (Module state and Timestamp)	0x200, 0x300, 0x400, 0x500, 0x600 (Respectively)	Motor, Sensor, Geo, Bridge, IO (Respectively)
0x101	1hz Periodic	Send Vehicle State	N/A	Motor, Sensor, Geo, Bridge, IO
0x124	Spontaneous	Set Torque and Steering	N/A	Motor
0x140	Spontaneous	Send Destination GPS	N/A	Geo
0x14A	Spontaneous	Request Calibrate Compass	N/A	Geo
0x14B	Spontaneous	Request Compass Heading	N/A	Geo
0x14C	Spontaneous	Request Current GPS	N/A	Geo
0x14D	Spontaneous	Request Current Time	N/A	Geo

Motor CAN Communication Table

TX Message ID	TX Message Transmit Rate	TX Message Description	RX Response Message ID	RX Listening Module
0x221	1z Periodic	Transmits forward speed and neutral steer values.	N/A	I/O

Sensor CAN Communication Table

TX Message ID	TX Message Transmit Rate	TX Message Description	RX Response Message ID	RX Listening Module
0x330	10hz Periodic	Transmit all sensor's distances	N/A	Master, IO

Geo CAN Communication Table

TX Message ID	TX Message Transmit Rate	TX Message Description	RX Response Message ID	RX Listening Module
0x441	10hz Periodic	Transmit Current GPS Coordinates	N/A	Master, IO
0x445	10hz Periodic	Transmit Current Heading and Bearing	N/A	Master, IO
0x449	10hz Periodic	Transmit Current GPS Heading	N/A	Master, IO
0x465	Spontaneous	Signal User that Calibration is complete	N/A	I/O

Bridge CAN Communication Table

TX Message ID	TX Message Transmit Rate	TX Message Description	RX Response Message ID	RX Listening Module
0x050	Spontaneous	Request Drive Mode change to Free Drive	N/A	Master
0x051	Spontaneous	Request Drive Mode change to GPS Drive	N/A	Master
0x052	Spontaneous	Request Drive Mode change to Indoor Drive	N/A	Master
0x053	Spontaneous	Transmit Destination GPS Coordinates	N/A	Master
0x055	Spontaneous	Request Vehicle Start Driving Command	N/A	Master
0x056	Spontaneous	Request Vehicle Turn Off	N/A	Master
0x057	Spontaneous	Request Vehicle Turn On	N/A	Master
0x058	Spontaneous	Send Free Drive Turn Left	N/A	Master
0x059	Spontaneous	Send Free Drive Straight	N/A	Master
0x05A	Spontaneous	Send Free Drive Turn Right	N/A	Master
0x05B	Spontaneous	Send Free Drive Stop	N/A	Master
0x05C	Spontaneous	Send Free Drive Reverse Left	N/A	Master
0x05D	Spontaneous	Send Free Drive Reverse Straight	N/A	Master
0x05E	Spontaneous	Send Free Drive Reverse Right	N/A	Master

IO CAN Communication Table

TX Message ID	TX Message Transmit Rate	TX Message Description	RX Response Message ID	RX Listening Module
0x060	Spontaneous	Request Drive Mode change to Free Drive	N/A	Master
0x061	Spontaneous	Request Drive Mode change to GPS Drive	N/A	Master
0x062	Spontaneous	Request Drive Mode change to Indoor Drive	N/A	Master
0x063	Spontaneous	Request Vehicle Turn On	N/A	Master
0x064	Spontaneous	Request Vehicle Turn Off	N/A	Master
0x065	Spontaneous	Transmit Destination GPS Coordinates	N/A	Master
0x066	Spontaneous	Request Vehicle Start Driving Command	N/A	Master
0x067	Spontaneous	Start Geo Calibration	N/A	Geo

Testing

---

Sensor Controller Testing

Sensor Controller Testing #1

Describe how you tested the Sensors Sensors are calibrated prior to any testings. 1. For individual sensors: Set a obstacle(36" x 48" poster board) in front of a sensor and sensor team verifies the sensor values with a ruler. Repeat this process with different distances (20cm, 40cm,and 60cm). 2. Detect any outlier: Set a obstacle and allow sensor to detect for period of time and sensor team verifies values within the period. If there were outliers, sensor team would verify the wiring or write a filtering algorithm. 3. Integrated test: After all sensors are tested individually, sensor team tested collaboratively with master. Sensor team would sent CAN message (5 sensor values) to master team and check if master team can perform certain operations according to different sensor values.

---

Motor Controller Testing

Motor Controller Testing #1

Testing for the motor was done using a digital oscilloscope to probe for PWM signals. Through the usage of Preet's PWM API, various values were tested to find the range of usable values in order to attain a PWM signal width of 1ms to 2ms. It was found that using a PWM frequency of 100hz, a range between 10 and 20 were representative of a PWM duty cycle of 0% to 100%. 0%~49% equated to a left steer or a reverse throttle, while 51%~100% equated to a right steer or forward throttle. To get neutral steer or zero throttle, a 50% duty cycle was used.

However, a lot of trial and error testing were done to find suitable speeds and steering ratios. This had to be done manually by testing value ranges and physically running the car to hand pick PWM values that allowed the car to move in a slow, but steady pace.

---

I/O Testing

I/O Testing #1: uLCD UART Communication

Testing the following API calls:

-Write String

-Write int to String

-Write float to String

-uLCD TX events

I/O Testing #2: CAN COMMUNICATION

Tested if messages are sending and receiving tasks are operating correctly

I/O Testing #3: Data Processing

Tested if all tasks are processing the CAN frames appropriately

---

Communication Bridge + Android Testing

Communication Bridge + Android Testing #1

Since commands can come from terminal the communication bridge was first tested this way. When sending the commands through terminal the SJone board should be able to print them back onto the terminal showing that the SJone board is accepting the commands and storing them into variables. Since the board is taking values and storing them successfully the next step was to test if sending commands from the android app would be successful. One problem that occurred when testing the android to SJone board bridge communication is that when sending commands the board would not print out the latitude and longitude values. The communication bridge changed the code to log in the values instead of printing them out, with these changes the group confirmed that the android application is sending correct values and the SJone board is storing them correctly. This was verified by viewing the log on the SJone board. The next and final process was to see if the master board is receiving the commands that is sent out from the bridge controller, and also if the sent latitude and longitude values will be printed onto the IO screen. Connecting the bridge controller to the car network and viewing the master terminal it verified that master is receiving the latitude and longitude values, and they are showing onto the IO screen. All the values were confirmed on the needed controllers and communication bridge works successfully.

---

Geographical Controller

Geographical Controller

There are two devices interfaced with the Geographical Controller, the GPS and compass. The GPS is responsible for retrieving the coordinates of the device's location and the compass is responsible for producing magnetometer and accelerometer data. Therefore there are three things that must be tested: GPS, magnetometer, and accelerometer data. There are simple test cases that could be made to verify that the values produced by these modules are correct. Take the GPS module for example, by comparing the latitude and longitude from the module to the true values of it's location (from Google maps), one can verify the robustness of the device.

---

Master Controller

Master Controller Testing

We tested master controller by working directly with each individual module team. We would test communication over CAN with each module then test functionality with each module. We tested master controller by doing integration test with sub module teams into the overall vehicle.

Technical Challenges

Sensor Controller Team Issues

MY ISSUE #1 Unreliable sensor values

PROBLEM: Fluctuating sensor values

RESOLUTION: Implement a sensor filtering function that discard the values that are considered as outliers. 5 sensor values were taken and average to get the final sensor value. This way makes the values more stable. We also compare the current sensor value and the previous sensor value and see if the difference is within tolerance, if it's not, the current value will be discarded and replace by the previous value.

FUTURE RECOMMENDATIONS: Read the data sheet carefully and test the sensor thoroughly before pass sensor values to the next team.

MY ISSUE #2 Bad hardware connections

PROBLEM:Bad hardware connections: A lot of time were wasted in software debugging, which the issue was in hardware.

RESOLUTION: Solder all sensor pin connections.

FUTURE RECOMMENDATIONS: Before any software debugging, the hardware connections must be the first area to check because it is the easiest and fastest.

Motor Controller Team Issues

Motor Controller Issue #1

PROBLEM: Going reverse during forward movement.

RESOLUTION: It was found out that a neutral-reverse-neutral-reverse signal had to be sent out with small amounts of vTaskDelay in order to do a reverse

FUTURE RECOMMENDATIONS: Find out how ESC unit controls reverse commands (no datasheets available).

Motor Controller Issue #2

PROBLEM: Braking during movement.

RESOLUTION: Go into neutral throttle and move wheels in the opposite direction of movement for a small amount of time.

FUTURE RECOMMENDATIONS: Try to learn how the ESC does a real brake, which should lock up the motor, thus preventing movement.

Motor Controller Issue #3

PROBLEM: How to vary speeds when going up a slope.

RESOLUTION: Use a speed sensor/wheel encoder to speed up car. (not able to implement)

FUTURE RECOMMENDATIONS: Prioritize mounting a hall sensor with magnetic strips as soon as motor module is able to control car movement.

I/O Team Issues

I/O Team Issue #1

PROBLEM:

Architecture which used a mutex to share UART lines between tasks was causing the button on the LCD display to not be very reliable.

RESOLUTION:

Instead of using a mutex, different priorities were used instead. The higher priority task will have complete control over the UART until it is done, however the higher priority task will only be active when there are user interactions with the LCD display.

FUTURE RECOMMENDATIONS:

Architectural design should be considered and planned out fully before coding.

I/O Team Issue #2

PROBLEM:

More performance enhancements needed to boost refresh rate for the LCD display. The display shows many different information (sensor values, motor information, etc.).

RESOLUTION:

Based on which form is activated on the screen (Sensor Form, Motor Form, etc.), the software would discard and not process information for other forms that do not need to be updated currently (with exception for Bridge).

FUTURE RECOMMENDATIONS:

Find areas for optimizations to better improve performance. If analyzed closer, there could be other areas which could improve performance, but the screen seemed sufficiently responsive now.

Communication Bridge + Android Team Issues

Communication Bridge + Android Issue #1

PROBLEM: The xbee that the group first purchased did not work, initial values were not being set to the xbee and a device would not recognize it.

RESOLUTION: The group came to the conclusion that the device was faulty, since the LEDs would not turn on. The group changed the xbee module, and ran the same code. This resulted in a successful communication from a bluetooth device and the SJone board.

FUTURE RECOMMENDATIONS: Buy a backup bluetooth xbee just in case one does not work.

Communication Bridge + Android #2

PROBLEM:When testing to see if the SJone board receives GPS coordinates from android app, the values would not print out onto the terminal screen.

RESOLUTION: Rewrote the code to log the information when it receives, the code also prints out the information through terminal. This confirmed that the board is receiving information from the android app.

FUTURE RECOMMENDATIONS: Try to use the log feature of the SJone board as much as possible.

Communication Bridge + Android #3

PROBLEM: After the implementation of the UART2 terminal interface, any use of UART2 through other tasks causes the terminal to act as if it receives a command multiple times. This would cause the bluetooth module to act erratically and stall.

RESOLUTION: Removed UART2 from FreeRTOS tasks that were not the terminal, moved the bluetooth initialization back to the main function for board start up.

FUTURE RECOMMENDATIONS: This solution was not ideal because there is only one window for connection after the module starts up, if the window is missed then the module is stuck in an error state until restart. Future groups may want to implement a status message that sends to the Master the bluetooth's connection status, so that the Master can send a command to return the module into pairing mode.

Geographical Controller Issues

Geographical Controller Issue #1

PROBLEM: Received a blend of multiple formats from the GPS module.

RESOLUTION:

FUTURE RECOMMENDATIONS:

Geographical Controller Issue #2

PROBLEM: Values from the accelerometer were not stable.

RESOLUTION: Implemented functions to calibrate. Upon boot, offsets are calculated by polling and averaging the values of x,y, and z at standstill and subtracting all those values from 0 (because 0 is the supposed values for x,y, and z during standstill). Whenever the accelerometer task grabs the values from the registers in the gps module, it will add the value of the corresponding offset, producing calibrated values.

FUTURE RECOMMENDATIONS: Create code to calibrate all modules to make sure the data produced are the same data that you're looking for before piecing the components together.

Master Controller Team Issues

Master Controller Issue #1

BACKGROUND Each of our sensors were supposed to transmit a value between 0 and 255 in centimeters. All sensor values are updated over CAN at a 10hz periodic rate.

PROBLEM: The consistency of a sensor value would fluctuate dramatically and never stay consistent with a tolerance of 5cm.

RESOLUTION: Ask the sensor team to filter their data.

FUTURE RECOMMENDATIONS: Make the sensor team filter their data.

Master Controller Issue #2

BACKGROUND Geo were supposed to transmit valid heading over CAN at a 10hz periodic rate.

PROBLEM: The consistency of a heading value would fluctuate dramatically and never stay consistent with a tolerance of 5 degrees.

RESOLUTION: Ask geo team to calibrate their heading data, that didnt work so go in and refactor their code.

FUTURE RECOMMENDATIONS: Make geo team to calibrate their heading data.

Master Controller Issue #3

BACKGROUND Geo were supposed to transmit valid gps latitude and longitude over CAN at a 10hz periodic rate.

PROBLEM: The consistency of the gps latitude and longitude value wouldn't update at a 10hz periodic rate

RESOLUTION: Ask geo team to fix freeRTOS priority and timing issues with updating GPS latitude and longitude.

FUTURE RECOMMENDATIONS: Make geo team to fix their priority and timing issues with updating GPS latitude and longitude.

Master Controller Issue #4

BACKGROUND Geo were supposed to transmit valid bearing over CAN at a 10hz periodic rate.

PROBLEM: The geo module would miss/drop CAN message from master that contains the next GPS destination.

RESOLUTION: Ask geo team to ensure no CAN messages are dropped or missed.

FUTURE RECOMMENDATIONS: Make geo team to ensure no CAN messages are dropped or missed.

Master Controller Issue #5

BACKGROUND The vehicle would compare current GPS location to destination GPS location to determine if the vehicle should stop

PROBLEM: The algorithm to compare current GPS latitude and longitude to destination GPS latitude and longitude was comparing current latitude minus destination longitude. Because of this, the GPS comparison would be remotely close.

RESOLUTION: Fix current latitude to compare with destination latitude and current longitude with destination longitude.

FUTURE RECOMMENDATIONS: Don't make mistakes.

Conclusion

Overall, the team can conclude this project to be a success. Advice to future students taking this class is to establish clear goals for each individual team member. For each subteam, tailor each team member's goal to their strengths to create an overall effective subteam. Even though the weather, GIT, hardware, and FreeRTOS may have been common obstacles everyone faced, the team was able to successfully create a self driving GPS RC car via 6 subsystems using CAN communication. The team learned other important skills as well, including: team dynamics, hardware interference, various protocols, algorithms, and team workflow. These skills that were gained through this project can be scaled into other projects within the field.

Project Video

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

Project Source Code

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