Difference between revisions of "F14: Self Driving Undergrad Team"
Proj user8 (talk | contribs) (→Communication Bridge + Android Software Design) |
Proj user8 (talk | contribs) (→Communication Bridge + Android Software Design) |
||
Line 1,915: | Line 1,915: | ||
After this is checked, the terminal task and RX/TX tasks are initialized. | After this is checked, the terminal task and RX/TX tasks are initialized. | ||
+ | |||
+ | '''Terminal Task (High Priority)''' | ||
+ | |||
+ | asdf | ||
+ | |||
+ | '''RX/TX Task (Medium Priority)''' | ||
+ | |||
+ | asdf | ||
==== Geographical Controller Team Software Design==== | ==== Geographical Controller Team Software Design==== |
Revision as of 05:38, 22 December 2014
Contents
- 1 Grading Criteria
- 2 Chi Lam
- 3 Self-Driving Autonomous Car
- 4 Abstract
- 5 Objectives & Introduction
- 6 We are
- 6.1 Schedule
- 6.2 Parts List & Cost
- 6.3 Design & Implementation
- 6.3.1 Hardware Design
- 6.3.2 Sensor Controller Team Hardware Design
- 6.3.3 Motor Controller Team Hardware Design
- 6.3.4 I/O Team Hardware Design
- 6.3.5 Communication Bridge + Android Hardware Design
- 6.3.6 Geographical Controller Team Hardware Design
- 6.3.7 Master Controller Team Hardware Design
- 6.3.8 Hardware Interface
- 6.3.9 Software Design
- 6.3.9.1 Sensor Controller Team Software Design
- 6.3.9.2 Motor Controller Team Software Design
- 6.3.9.3 Motor Movement Commands
- 6.3.9.4 I/O Team Software Design
- 6.3.9.5 Communication Bridge + Android Software Design
- 6.3.9.6 Geographical Controller Team Software Design
- 6.3.9.7 Master Controller Team Software Design
- 6.3.10 Software Interface
- 6.3.10.1 Sensor Controller Team Software Interface
- 6.3.10.2 Motor Controller Team Software Interface
- 6.3.10.3 I/O Team Software Interface
- 6.3.10.4 Communication Bridge + Android Software Interface
- 6.3.10.5 Geographical Controller Team Software Interface
- 6.3.10.6 Master Controller Team Software Interface
- 6.3.10.7 CAN Communication Table
- 6.4 Testing
- 6.5 Technical Challenges
- 6.6 Conclusion
- 6.7 References
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 | Complete. |
4 | 11/3 | Create basic Android application | Complete (completed ~10/18). |
5 | 11/10 | Add map onto the Android application | Complete (completed ~10/25). |
6 | 11/17 | Send/receive CAN Messages via Android Application | Complete (sending completed ~10/18, receiving ~11/1). |
7 | 11/24 | Debug and Optimize Android Application | Complete. |
8 | 12/1 | Continue Debugging and Optimizing as Necessary | Complete. |
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:
|
|
SN65HVD230 CAN Board Transceiver:
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. |
|
3D Printed Materials:
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
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 XL-5 Electronic Speed Control (ESC) Unit:
|
|
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:
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. |
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:
|
|||||
Adafruit LSM303 Compass:
|
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
Bridge Team listens for 0x100, the heartbeat message, and then responds with an acknowledgment message including Bridge's state loaded into the message. Messages sent from the Android application are processed using the terminal task and then sent into the CAN bus.
Messages are sent into and received from the Bluetooth module through UART frames. The Bluetooth module's baud rate is adjustable, and set to 38400 on board startup. The UART2 on the SJOne board is also set up to the same baud rate. Messages sent to the Bluetooth module are also encapsulated through the following format:
/r/n[message]/r/n
On board start up, the Bluetooth module's settings are changed in order to prepare it for connection to the Android device. These settings include setting the Bluetooth module's baud rate, pairing mode, and device name. Once the settings are changed, the command to set the module into pairing mode is sent.
GPS coordinates must be sent to the master as floating point values. In order to send floating point values through CAN, the data must be interpreted correctly so that the data can be read from the Master side. Latitude and longitude coordinates are formatted using the following line of code:
msg.data.dwords[0] = *(reinterpret_cast<uint32_t*>(&latitude));
This code shows that the first 4 bytes of the CAN message data are assigned to the value of the "latitude" variable. Template:Clear
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
Prior to initializing tasks. a Bluetooth connection check function is called. This function blocks the system from initializing tasks until a successful Bluetooth connection is established. This check function watches the UART2 channel (where the Bluetooth module is connected) and checks for a specific string before it allows the tasks to be initialized. The string is sent from the Android device once it successfully initiates a data connection with the SJOne board.
The communication bridge software design is comprised of two tasks: terminal task and an RX/TX task.
After this is checked, the terminal task and RX/TX tasks are initialized.
Terminal Task (High Priority)
asdf
RX/TX Task (Medium Priority)
asdf
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 uLCD API calls:
-Write String - Able to write a simple "Hello World" onto the uLCD
-Write int to String - Able to write an integer variable onto the uLCD
-Write float to String - Able to write a float variable onto the uLCD
-uLCD TX events
I/O Testing #2: CAN COMMUNICATION
-CAN RX - Tested if all CAN messages on the BUS are being received on time
-CAN TX - Tested if all CAN messages being sent on time BUS on time
I/O Testing #3: Data Processing
-Event Handler Task - Tested if all uLCD operations are being handled and sent to the CAN Bus
-RX Task - Tested if all messages are received, processed, and displayed onto the uLCD
Communication Bridge + Android Testing
Communication Bridge + Android Testing #1: Terminal Commands
Two new terminal commands were added to the existing terminal task: bluenav (for sending coordinates over CAN) and bluecmd (for sending other messages over CAN). In order to test the functionality of these commands, a logging function was built into each new function. Various commands were sent to the terminal, the log file was subsequently viewed, and it was confirmed that these two terminal tasks parsed the inputs properly and would send the expected messages.
Communication Bridge + Android Testing #2: Android Bluetooth messages
The Android application's message sending functionality was tested. First, the Android device was paired with a laptop. After successful pairing, a serial terminal was opened between the laptop and Android device via Bluetooth. Buttons were pressed on the Android application, and it was confirmed that the expected messages were being sent from the Android application over Bluetooth, as they could be read in the serial terminal on the laptop.
Communication Bridge + Android Testing #3: Full System
After confirming operation of the Android application and the new terminal commands, the full system was tested. The bridge board was connected to the master board, and the Android device was paired with the SJOne board. Buttons were pressed on the Android application, and proper operation was confirmed in two ways: looking at the serial output of the master board and viewing sent GPS coordinates on the LCD screen. All messages were sent as expected.
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 purchased XBee Bluetooth module failed to connect to any devices.
RESOLUTION: It was noted that the LEDs on the XBee Bluetooth module did not turn on, and it was assumed that the device was faulty. A second XBee Bluetooth module was purchased, and this module operated properly using the same code.
FUTURE RECOMMENDATIONS: Buy at least two Bluetooth modules in the event that one is faulty.
Communication Bridge + Android Issue #2
PROBLEM:When testing to see if the terminal task received the expected messages, the values would not print to the terminal.
RESOLUTION: It was assumed that the terminal task was operating properly and receiving commands from Bluetooth but printing the information back over UART. The terminal command code was rewritten to log information received instead of print it. It was confirmed that messages were being received and parsed properly by the terminal task.
FUTURE RECOMMENDATIONS: Make extensive use of the built in logging function.
Communication Bridge + Android Issue #3
PROBLEM: After the implementation of the UART2 terminal interface, any use of UART2 through other tasks caused the terminal to act as if it received a command multiple times. This would cause the Bluetooth module to act erratically and stall.
RESOLUTION: Removed UART2 from all FreeRTOS tasks other than the terminal task. Created a Bluetooth initialization routine in the main function that would wait for a proper Bluetooth connection before starting the terminal task.
FUTURE RECOMMENDATIONS: Implement a watchdog function that will reboot the board upon termination of Bluetooth connections.
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
References
Acknowledgement
Any acknowledgement that you may wish to provide can be included here.
References Used
List any references used in project.