Difference between revisions of "F16: The-Nine"

Revision as of 20:16, 20 December 2016 (view source) Proj user8 (talk | contribs) (→‎Software Design) ← Older edit		Revision as of 20:17, 20 December 2016 (view source) Proj user8 (talk | contribs) (→‎GPS Data Format) Newer edit →
Line 826:		Line 826:
	|-		|-
	|}		|}
−
−	After parsing the NMEA string, the correct heading must be calculated to help orient the car in the correct direction. When the correct heading is calculated, the current and correct heading are both sent in a single CAN message to the master controller.
	=== Implementation ===		=== Implementation ===

---

Revision as of 20:17, 20 December 2016

Project Title

The-Nine: Self Driving Car

Abstract

This section should be a couple lines to describe what your project does.

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.

Show a simple table or figures that show your scheduled as planned before you started working on the project. Then in another table column, write down the actual schedule so that readers can see the planned vs. actual goals. The point of the schedule is for readers to assess how to pace themselves if they are doing a similar project.

Project Schedule Overview

Task #	Start Date	End Date	Team Task Description	Bluetooth Communications	Obstacle Detection Systems	Localization and Positioning (GPS)	Propulsion Systems and Speed Tracking	Master Control Systems	Status	Actual End Date
1	9/14/2016	9/20/2016	Assigned tasks to one another and strategized approach. Read Previous Reports						Completed	9/20/2016
2	9/21/2016	9/27/2016	Set up Version Control System and Basic Project Documentation Research Project Components	Research of web application frameworks for mobile.	Research of sensor systems and sensor types needed.	* Researched and decided upon the GPS module and Compass module. * Ordered GPS module and compass module.	Work with team leader to devise version control strategy.	Research different RC cars for the project.	Completed	9/27/2016
3	9/28/2016	10/04/2016	Discuss controllers' responsibilities and communication	Started development of DBC and finalized hardware choices.					Completed	10/04/2016
4	10/05/2016	10/19/2016	Order Project Components Individual Prototyping and Module Design	Research Bluetooth device HC-06 for the RC car.	Interface IMU and ultrasonic sensors to board.	* Parse GPS data and format the data to be transmitted * Test code to get compass reading information	Research what encoders and/or tachometers to use, help the team leader choose an RC car to purchase, and decide what motor driver to use	Implement Decision Tree for obstacle detection/autonomous car control. Decide on Message ID system over the CANBUS/Types of Data being Transmitted	Completed	10/19/2016
5	10/20/2016	10/27/2016	Status Update: Demoing first round of Prototyping to the group	Develop Bluetooth serial receiver library & web application.	Develop IMU and ultrasonic sensor libraries.	Interface GPS module and compass module to SJOne board.	Make the motors spin and the servo control the steering. Receive can signals and control the motor and steering servo.	* Implement Decision Tree for obstacle detection/autonomous car control. Decide on Message ID system over the CANBUS/Types of Data being Transmitted * Program obstacle detection/autonomous car control algorithms	Completed	10/27/2016
6	10/28/2016	11/18/2016	Adding a level of complexity to designs: Interfacing Motor, Sensor, GPS, and Bluetooth Modules with the Master Controller over CAN bus	Integrate web application, SJOne board and DBC messages	Use implemented DBC to transmit sensor data over CAN.	* Calibrating the compass module.Integration of GPS and compass module. Interfacing of GPS and compass module to Android. * Integration with Master through CAN bus.	* Validate and calibrate the motor controller and steering code. Receive the Tachometer and magnetic polarity strip. * Merge motor_test/tach with master. * Reorganize code for readability. * Finalize and test speed feedback system.	* Program obstacle detection/autonomous car control algorithms * Test RC car obstacle detection and autonomous control interfaced with Sensor Module over CAN * Interface GPS module with Master Controller * Interface Android/Bluetooth module with Master Controller.Test Waypoint System	Completed	11/18/2016
7	11/19/2016	11/25/2016	Integration Testing between Modules, System Validation	Fine-tuning of web application	Debug sensor library and work on integration	Testing and calibrating with other modules.	Test with the rest of the group * Fine tune nominal speed. Add LCD to display debug information.	* Interface Android/Bluetooth module with Master Controller.Test Waypoint System * Debug any issues with Master controller and other modules	Completed	11/28/2016
8	11/26/2016	12/02/2016	Overall System Optimization		Fine-tuning of sensor readings	Testing and calibrating with other modules.	* Replace motor driver with higher amperage driver. * Adjust steering offset to reduce error.	* Debug any issues with Master controller and other modules * Final debug/testing of RC CAR	Completed	12/04/2016
9	12/03/2016	12/09/2016	Finalization, Preparing for Demonstration						In Progress

Team Members & Responsibilities

Application & Control Interface

• Khalil Estell

Bluetooth Communications

• Khalil Estell

Obstacle Detection Systems

• Charles MacDonald
• John Strube

Localization and Positioning (GPS)

• Sara Sepasian

Propulsion Systems and Speed Tracking

• Derek Tran
• Matthew Boyd

Master Control Systems

• Steven Hwu
• Adam Iglesias

Parts List & Cost

Give a simple list of the cost of your project broken down by components. Do not write long stories here.

Item #	Part Description	Vendor	QTY	Cost
1	RC Car		1
2	SJSUOne Board	Preet Kang	5	$400.00
3	HC-06 Bluetooth Module	Amazon	1	$8.99
4	Magnetic Tachometer	Digikey	1	$8.53
5	Radial Magnet cube magnets	Digikey	10	$8.80
6	High Power Motor Driver	Polulu	1	$39.95

Bluetooth Communications (Communication Bridge)

Team Members: Khalil Estell

Schedule

Task #	Start Date	End Date	Task Description	Status	Actual End Date
1	9/14/2016	9/20/2016	Assigned tasks to one another and strategize approach.	Completed	9/20/2016
2	9/21/2016	9/27/2016	Research of web application frameworks for mobile.	Completed	9/27/16
3	9/28/2016	10/04/2016	Started development of DBC and finalized hardware choices.	Completed	10/04/2016
4	10/05/2016	10/19/2016	Research Bluetooth device HC-06 for the RC car.	Completed	10/19/2016
5	10/20/2016	10/27/2016	Develop Bluetooth serial receiver library & web application.	In Progress
6	10/20/2016	11/18/2016	Integrate web application, SJOne board and DBC messages	In Progress
7	11/19/2016	12/02/2016	Fine-tuning of web application	Not started
8	12/03/2016	12/09/2016	Final integration	Not started

Design & Implementation

Hardware Design

Discuss your hardware design here. Show detailed schematics, and the interface here.

Hardware Interface

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

Software Design

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.

Implementation

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

Testing & Technical Challenges

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

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

My Issue #1

Discuss the issue and resolution.

Obstacle Detection Systems (Sensor Controller)

Team Members: John Strube, Charles MacDonald

Schedule

Task #	Start Date	End Date	Task Description	Status	Actual End Date
1	9/14/2016	9/20/2016	Assigned tasks to one another and strategized approach.	Complete	9/20/2016
2	9/21/2016	9/27/2016	Research of sensor systems and sensor types needed.	Complete	9/27/2016
3	9/28/2016	10/04/2016	Started development of DBC and finalized hardware choices.	Complete	10/04/2016
4	10/05/2016	10/19/2016	Interface IMU and ultrasonic sensors to board.	Complete	10/19/2016
5	10/20/2016	10/27/2016	Develop IMU and ultrasonic sensor libraries.	Complete	10/19/16
6	10/20/2016	11/18/2016	Use implemented DBC to transmit sensor data over CAN.	Complete	10/19/16
7	11/19/2016	11/25/2016	Debug sensor library and work on integration	Complete	11/25/16
8	11/26/2016	12/02/2016	Fine-tuning of sensor readings	Complete	12/1/16
9	12/03/2016	12/09/2016	Final integration	Complete	12/8/16

Design & Implementation

The obstacle detection system covers two areas: detecting obstacles and determining vehicle orientation.

Obstacle detection is performed using ultrasonic sensors placed around the perimeter of the vehicle, concentrated at the front (three sensors) and less so in the back (one sensor) as the vehicle is primarily driven in the forward direction.

Vehicle orientation is accomplished using an inertial measurement unit, which is used to determine the speed and bearing of the vehicle.

Hardware Design

Ultrasonic sensors

Ultrasonic sensors are controlled using GPIO. The sensor consists of a trigger-input signal which causes it to emit sound at a specific frequency, and a echo-output signal which is pulsed when a reflection of the same frequency is received. The echo response is detected by the edge-sensitive GPIO interrupt, and the trigger is produced by a software-generated pulse.

Compass

A magnetometer is used to calculate the heading of the car. The magnetometer being used is the HMC5883L. The magnetometer measures the magnetic field of The Earth in units of Tesla as scalars in the X, Y and Z axis. The SJOne board communicates with the magnetometer using I2C at address 0x3C. An accelerometer onboard the SJOne board is used for tilt compensation. The magnetometer is oriented such that X axis faces forward, Z axis faces up, and Y axis faces to the left.

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.

Ultrasonic sensors

The MB1010 sensors have a ranging request trigger input (RX) and a ranging value output (PW). The PW signal produces an high-level pulse width that is proportional to the distance of an obstacle. The RX signal is used as follows:

Level	Current state	Function
Low	Idle	Remain idle.
Low	Ranging	Inhibit ranging after current ranging completes.
Floating	Any	Range continuously.
High (0 < t < 20us)	Idle	Remain idle.
High (20us < t < 50us)	Idle	Start ranging
High (t > 50us)	Ranging	Range continuously.

The ranging value output is an active-high pulse, whose width of which indicates the time delay it took for the sensor to detect an echo from an obstacle.

Ranging modes

There are two common modes of operation for the sensor based on how the RX input is used:

1. Continuous ranging: Hold RX high or allow it to float to range continuously. RX can be held low to temporarily stop ranging when needed.
2. On-demand ranging: Pulse RX high for at least 20us but less than 50ms to range once.

For our implementation on-demand ranging is used to give fine control over when the sensors are active.

Ranging operation

The sensor can perform a ranging operation every 50ms. When idle (not ranging) the sensor continuously polls the RX input. It will begin ranging if it has detected a high or floating level on the RX pin continuously for at least 20us.

After detecting this condition it will drive the PW output high about 1ms later. This indicates that an echo pulse has been emitted from the sensor and that ranging has begun. PW remains high until one of two conditions are met:

1. The echo is detected.
2. Time-out: 37.5ms have elapsed.

A time-out occurs when the sensor detects no obstructions, or obstructions are beyond the 254-inch range.

Error conditions

There are several possible error conditions:

• No high level on PW after triggering. The RX input may not have been asserted for a minimum of 20us, or the input may have sufficient noise to fall below the high-level detection threshold such that it did not appear continuous.
• No low level on PW after it goes high. This is an abnormal condition where the output is stuck high. It can only be resolved by cycling the power to reset the sensor.

Controlling multiple sensors

The timer peripheral is used to measure the response from the ultrasonic sensors. This is done through the capture feature which can be used to read a free-running timer in hardware when events such as a positive or negative edge on the PW output occurs.

Timer overview

The timer capture feature that copies the current timer count (TC) into a compare register (CR) when an event such as a positive or negative edge occurs. An interrupt can also be triggered when a capture happens. On the SJOne board, the only capture pins available are for Timer #1, and they are allocated like so:

• Timer 1, capture channel #0 (CAP1.0 on P1.18) goes to header X3, pin 3 (/IRDATA) and is shared with the infrared (IR) interface.
• Timer 1, capture channel #1 (CAP1.1 on P1.19) goes to header X1, pin 4.

In order to use CAP1.0 you must physically remove the infrared receiver/transceiver from the SJOne PCB. By default the SJOne software uses Timer #1 for watchdog and IR communication. You must edit sys_config.h and change SYS_TIMER from 1 to any other available timer (0, 2, or 3) to prevent conflicts with the watchdog feature.

Glitch filtering

The capture function samples an input pin during two successive PCLKs. The frequency of PCLK defines how narrow of a pulse can be detected. At high PCLK rates very narrow pulses such as those caused by glitches and noise can be detected. Because the ultrasonic sensor pulses are very wide (in the millisecond range) a slow PCLK is acceptable to reject spurious pulses on the capture input.

Timer use

The process of reading a sensor follows the following steps:

1. Assert the RX pin for 20ms to request ranging.
2. Set the match register to trigger a time-out interrupt in 50ms.
3. Idle until a positive-edge capture interrupt occurs. The ISR reads and saves the captured timer count.
4. Idle until a negative-edge capture interrupt occurs. The ISR reads the captured timer count and computes the delta (elapsed time) from the positive edge capture.

The time-out match register is used to to determine when the sensor missed a rising or falling edge (error conditions), so that the sensor status can be updated to reflect that no data could be read.

Improving refresh rate

We were able to make a significant improvement to the sensor refresh rate by starting ranging of the next sensor as soon as the current one finished (negative edge on PW received) or timed out. In this way the total sensor update rate is dynamic. For four sensors the slowest refresh rate is 50ms x 4 = 200ms (5 Hz), and the fastest is 2.88ms x 4 = 11.52ms (86 Hz). As the upper limit for repeated ranging for a single sensor is 20 Hz, if all available sensors can be read in under 50ms the sensor system simply idles until the remaining time out of a 50ms interval has elapsed.

Development suggestions

Looking at the sensor trigger and echo outputs on a logic analyzer was invaluable for getting an idea how different ranging distances worked and what the edge cases were. We added a dedicated logic analyzer connector on our PCB to simplify monitor these signals.

Compass

The SJOne board communicates with the HMC5883L using I2C bus 2, using slave address 0x3C.

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.

Compass

The compass headings are calculated 10 times a second using the period_10Hz task in period callbacks. An exponential moving average is used to smooth out the raw magnetometer and accelerometer data. A weight of .5 was used to smooth out the magnetometer, and a weight of .1 was used to smooth out the accelerometer. The magnetic and acceleration vectors as measured from the magnetometer and accelerometer are then normalized such that the length of the vectors is 1.0. Because a gyroscope is not being used to assist in tilt compensation, a very low weight must be used to compensate for the car accelerating forward and backward. Tilt compensation is used to ensure an accurate compass reading when the car is titled. The tilt compensation algorithm uses the roll and pitch as calculated from the accelerometer and the X Y and Z components of the normalized magnetometer vector. The calculated heading is then converted from radians to degrees. The magnetic declination offset angle is then added to the heading to account for the differences between magnetic and true north. The heading will then be sent to Master, BlueTooth, and Debug over Can bus.

Implementation

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

Compass

To communicate with the magnetometer sensor, a singleton class named IMU_Sensor was created. The class stores sensor data in a local struct, and handles initialization of the sensor, and reading raw magnetometer sensor data.

Measuring the raw sensor data

The IMU_Sensor class communicates with the magnetometer using I2C at address 0x3C. The period_init function in periodic callbacks calls the init function, which sets the two configuration registers and the mode register using the I2C2 class. Ten times per second the periodic scheduler calls the getXYZ() function. Six registers are read, starting at 0x03, which store the high and low bites for the X, Z, and Y axis of the magnetometer. If the readRegisters function returns false, the getXYZ function returns false. A zero byte is then written to register 0x03 to reset the internal pointer and prepare for the next measurement. The table below lists the relevant registers.

Address Location	Name
0x00	Configuration Register A
0x01	Configuration Register B
0x02	Mode Register
0x03	Data Output X MSB Register
0x04	Data Output X LSB Register
0x05	Data Output Z MSB Register
0x06	Data Output Z LSB Register
0x07	Data Output Y MSB Register
0x08	Data Output Y LSB Register

Calculating Heading

The period_10Hz reads the raw values from both the magnetometer using the IMU_Sensors class, and from the accelerometer using a built in class. The raw data is then filtered using an exponential moving average, with a weight of 0.5 for the magnetometer and 0.1 for the accelerometer. The magnetometer and accelerometer vectors are then normalized. Roll and pitch are then calculated using the normalized accelerometer vector. The roll is calculated by taking the arcsin of the negative X component, and the pitch is calculated by taking the arcsin of the Y component. The following formula is used to calculate the tilt compensated vector.

hy = normHy * cos(roll) + normHx * sin(roll) * sin(pitch) - normHz * cos(pitch) * sin(roll)

hx = normHx * cos(pitch) + normHz * sin(pitch)

The heading in radians is then calculated by taking the arctan of the Y and X components of the tilt compensated vector. The declination angle (13 degrees for San Jose) is then added to the current heading. The heading in radians is then converted into degrees. The heading in degrees is then sent over Can Bus to be received by Master, Bluetooth, and Debug.

Testing & Technical Challenges

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

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

Ultrasonic sensors

Recalibration

The MB1010 sensor calibrates itself when power is applied. According to the manufacturer it requires recalibration when the operating voltage, temperature, or location changes. This need seems to have manifested itself as a condition where after normal operation for some duration of time a sensor begins to report the minimum distance (~14cm) regardless of what is in front of the sensor. This behavior persists until power is cycled, at which point recalibration occurs.

My solution was to add a TPS2034 two-channel power switch to manually cycle the sensor power rails under software control. To determine when recalibration is needed, the past history of sensor readings are scanned to see if any are stuck and are always reporting the minimum distance. If any are stuck the power is cycled using the TPS2034. This allowed the sensors to be recalibrated automatically.

The TPS2034 is a two-rail switch and was used to control the front (3) and rear (1) sensors. In retrospect a better use would be the TPS2054 which has four independent outputs, such that individual sensors could be recalibrated without disturbing the other ones.

RS-232 testing

The MaxBotix LV-MaxSonar-EZ1 (P/N# MB1010) has several interfaces used to indicate the distance to an obstacle that it has sensed. One of the simplest is a RS-232 output which is enabled by grounding the BW pin or leaving it unconnected (floating). The output is logic-level compatible with RS-232 (where a logic '1' is 0V and a logic '0' is Vcc) but not voltage-level compatible. MaxBotix designed the RS-232 output like this to allow direct connection to a RS-232 compliant serial port, but it means the logic levels are inverted with respect to the LPC1758 which has no on-chip provisions for inverting the logic level. Therefore an inverter (such as the 74LVC1G04) is required between the TX output of the MB1010 and the LPC1758's UART RX input for proper operation.

My Issue #1

Discuss the issue and resolution.

Localization and Positioning (GPS)

Team Members: Sara Sepasian

Schedule

Task #	Start Date	End Date	Task Description	Status	Actual End Date
1	09/16/2016	09/22/2016	Researched and decided upon the GPS module and Compass module.	Completed	09/22/2016
2	9/23/2016	9/30/2016	Ordered GPS module and compass module.	Completed	09/30/2016
3	10/01/2016	10/14/2016	Parse GPS data and format the data to be transmitted Test code to get compass reading information	Completed	10/04/2016
3	10/15/2016	10/25/2016	Interface GPS module and compass module to SJOne board.	Completed	10/19/2016
4	10/26/2016	10/30/2016	Calibrating the compass module.Integration of GPS and compass module. Interfacing of GPS and compass module to Android.	Completed	10/19/2016
5	11/01/2016	11/13/2016	Integration with Master through CAN bus.	Completed	10/19/2016
6	11/15/2016	12/10/2016	Testing and calibrating with other modules.	Completed	12/08/2016

Design & Implementation

The GEO Controller is responsible for calculating/ providing the location which the car is currently at and target direction to the master controller and bluetooth. The GEO controller will receives the way-points from the Bluetooth Controller and calculates the target heading to the closest waypoint an. The Master Controller is still responsible for controlling the logic of forward, backward, left, and right to reach the final destination. We were able to receive data from GPS module at 10Hz and communicate at 38400bps through UART. We sent specific data packets to receive the GPS module to be able to read the $GPGGA( Global Positioning System Fix Data) string over the UART from the module.

Hardware Design

GPS module used in our project is Adafruit Ultimate GPS Breakout - 66 channel w/10 Hz updates - Version 3 and GPS external active antenna. We were able to configure this module at 10Hz and communicate at 38400bps through UART. The GPS module had 10Hz update rate with low current draw which helped power usage very low. The GPS module GPS can also be configured to operate and communicate at various speed though the provided Graphical User Interface. This module has got an on-board flash to store these configuration which us a built in data-logging capability.

Hardware Interface

Hardware Interface

GEO Controller Pin Configurations

Device	Port Source	Port Destination	Device
SJ One	3v3	Vin	Adafruit GPS
SJ One	GND	GND	Adafruit GPS
SJ One	TXD3	RX	Adafruit GPS
SJ One	RXD3	TX	Adafruit GPS

Software Design

The GEO Controller is responsible for retrieving the data from GPS and parsing this information and calculate the needed values.

GPS Data Format

The Data that was retrieved from GPS is in NMEA 0183 format. NMEA is a combined electrical and data specification for communication between marine electronic devices such GPS receivers and many other types of instruments. The sting we received is in this format: $GPGGA,hhmmss.ss,llll.ll,a,yyyyy.yy,a,x,xx,x.x,x.x,M,x.x,M,x.x,xxxx*hh. Which each section describe an specific characteristic of the data. The following table shows format description of each substring within the received string from GPS module.

$GPGGA- Global Positioning System Fix Data

Name	Example Data	Description
Sentence Identifier	$GPGGA	Global Positioning System Fix Data
Time	170834	17:08:34 Z
Latitude	4124.8963, N	41d 24.8963' N or 41d 24' 54" N
Longitude	08151.6838, W	81d 51.6838' W or 81d 51' 41" W
Fix Quality	1	Data is from a GPS fix
# of Satellites	05	5 Satellites are in view
Horizontal Dilution of Precision	1.5	Relative accuracy of horizontal position
Altitude	170834	280.2 meters above mean sea level
Height of geoid above WGS84 ellipsoid	-34.0, M	-34.0 meters
Time since last DGPS update	blank	No last update
GGPS reference station id	blank	No station id
Checksum	*75	Used by program to check for transmission errors

Implementation

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

Testing & Technical Challenges

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

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

My Issue #1

Discuss the issue and resolution.

Propulsion Systems and Speed Tracking (Motor Controller)

Team Members: Matthew Boyd, Derek Tran

Schedule

Task #	Start Date	End Date	Task Description	Status	Actual End Date
1	9/14/2016	9/20/2016	Assigned tasks to one another and strategized approach.	Completed	9/20/2016
1	9/21/2016	9/27/2016	Work with team leader to devise version control strategy.	Completed	9/27/2016
2	9/28/2016	10/04/2016	Started development of DBC and finalized hardware choices.	Completed	10/04/2016
3	10/05/2016	10/19/2016	Research what encoders and/or tachometers to use, help the team leader choose an RC car to purchase, and decide what motor driver to use	Completed	10/22/2016
4	10/23/2016	10/27/2016	Make the motors spin and the servo control the steering. Receive can signals and control the motor and steering servo.	Completed	10/25/2016
5	10/26/2016	11/04/2016	Validate and calibrate the motor controller and steering code. Receive the Tachometer and magnetic polarity strip.	Completed	11/05/16
5	11/06/2016	11/11/2016	* Merge motor_test/tach with master. * Reorganize code for readability. * Finalize and test speed feedback system.	Completed	11/11/2016
5	11/12/2016	11/18/2016	validate the wheel speed control system and calibrate.	Completed	11/18/2016
6	11/19/2016	11/25/2016	Test with the rest of the group * Fine tune nominal speed. Add LCD to display debug information.	Completed	11/28/2016
7	11/29/2016	12/02/2016	* Replace motor driver with higher amperage driver. * Adjust steering offset to reduce error.	Completed	12/04/2016
8	12/06/2016	12/09/2016	Test with the rest of the group, and fix any minor issues that come up. * Finalize code and merge into master.	In progress

Design & Implementation

Hardware Design

The motor controller board takes charge of two main systems: motoring and steering.

To accomplish motoring, a high power motor driver from Polulu is used to drive the RC car's motor. It takes a simple digital signal for direction and a PWM signal for speed. To help control speed accurately, a tachometer and a set of magnets in a wheel are used to feed back rotations per second (rps). For debugging, a TFT display was connected to the SJSUOne board and displayed tachometer readings versus commanded readings. The figure on the right shows how the SJSUOne board is connected to the display and the motor driver. In addition, the block diagram also shows power connections from the battery.

Steering controlled as simply as the motor. A single wire is needed to feed a PWM signal to the servo. The figure below the motor connections image shows how the servo is connected.

Hardware Interface

Motor

The interface to the motor consists of two sections: feedback and output. The feedback section involves connecting the SJSUOne board to the FAULT and Current sense pins. This allows the board to stop or slow down the motor if problems or overcurrent situations appear. Then the output section consists of a simple digital signal and a PWM signal. The simple digital output controls the direction of the motor: HIGH motors the car forward and LOW motors the car in reverse. To manipulate speed, the duty cycle of the PWM signal is changed according to a PI control algorithm in the SJSUOne board. In order to avoid overcurrent problems, the PWM signal is kept at a high frequency such as 20 kHz.

Tachometer

The tachometer provides information about wheel rotation speed by pulling the its output line low every time the tachometer passes over the south pole of a magnet.

Servo

Controlling the servo requires just one PWM signal. Instead of the duty cycle, the on-time of the signal determines how far the servo turns the car to the left or right. For the servo on this car, the range is 1.300 to 1.900 ms, where 1.5 ms means straight. With this time range, the best frequency for this signal would be 50 Hz. However, since the SJSUOne board provides only one PWM module, a software PWM module was implemented to produce the signal.

TFT Display

A board from Adafruit, the TFT display used for this project communicates with the SPI protocol. However, the board also provides a reset pin and an SD card, so there are a couple of extra pins to choose which device to connect to. The SD card port may be used to log debugging information. For drawing the actual characters, a library from Adafruit was imported.

Software Design

Created Libraries

• Servo Driver (Uses a hardware timer attached to an interrupt to drives a servo at 50 HZ with 100 microseconds of resolution)
• Motor Controller (Runs the control loops that drive the main motor and steering)
• LCD Display Driver(Controls the LCD display. Most functions were imported from the Adafruit library for the device)
• Tachometer Driver (Sets-up/monitors an external interrupt and keeps track of the tachometer ticks)

All code on this SJSU-Oneboard software was separated into two running tasks, the Periodic Scheduler and the LCD Display task. The LCD Display was put into its own task due to the need for specific timing requirements that are randomized and large. Typically a custom delay system should be created and put into the periodic scheduler but the LDC display is a low priority objective and a separate task handles its requirements adequately. The periodic scheduler runs every other task on the system. The two subsystems of the periodic scheduler that run on different timing requirements are both the interrupts for the tachometer and the servo hardware timer. Both of these Interrupts are set as lower priority than the periodic scheduler interrupts and RTOS interrupts. This does causes a gap in the hardware timer's control signal for the servo, however the gap is not often enough to cause the servo issues. Furthermore the gap is outside the range of input to the servo so whenever the gap happens, the servo completely ignores it.

Implementation

Motor Control System

Using the 10 Hz periodic scheduler task with a counter, the Motor Control system runs every half a second. This amount of time was selected from the low resolution of eight tachometer ticks per rotation of the car's wheel. In general, the greater the resolution of your feedback in a closed loop system, the faster your control loop can run. Within the Control loop, a system similar to a PI(Proportion, Integral) system was used. When a command from the master controller is sent, that value will get multiplied by a constant and added with an offset. The offset is simply an incremented or decremented value that gets changed according to how far the motors actual speed is from its targeted speed. The Final value is then fed to the motors as a percentage to the PWM I/O that controls the motor's speed.

Hardware Timer Workings

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

Testing & Technical Challenges

Motor Driver control

Several times during testing, the SJSUOne board was powered up or reprogrammed while still connected to the motor driver, causing the motor to rev at full speed and destroy the motor driver. The first solution to avoid full speed upon board power up was to add a tri-state buffer between the output of the SJSUOne board and the motor driver. Later on, the team discovered that a single pull-down resistor on the line was sufficient to solve the issue. This taught the team that for future projects involving powered mechanical systems to always make sure the control line by default will keep the systems off, whether by pull-down resistors or tri-state buffers.

PWM accuracy

While testing servo control, the frequency of the generated PWM signal proved to be inaccurate. The generated signal would have a frequency 10 times greater than what is set in the program, leading to inaccurate on-times. The team soon found out that the problem was because of where the PWM object in the program was constructed. Initially, the PWM objects were created in the global scope, meaning the constructor would write to the registers before the main() function was entered. While this problem is not fully understood, it was solved by constructing the objects in init() functions, which were called after the main() function was entered. This shows that, for future drivers written for microcontrollers, driver behaviour would be much more well defined if all register manipulation happened in an init() member function rather than in a constructor. This way, client users do not have to worry about accidentally constructing driver objects in the global scope.

Master Control Systems

Team Members: Steven Hwu, Adam Iglesias

Schedule

Task #	Start Date	End Date	Task Description	Status	Actual End Date
1	9/14/2016	9/20/2016	Assigned tasks to one another and strategized approach.	Complete	9/20/2016
2	9/21/2016	9/27/2016	Research different RC cars for the project.	Complete	10/15/2016
3	10/16/2016	10/23/2016	Implement Decision Tree for obstacle detection/autonomous car control. Decide on Message ID system over the CANBUS/Types of Data being Transmitted	Complete	10/23/2016
3	10/24/2016	10/29/2016	Program obstacle detection/autonomous car control algorithms	In Progress
4	10/30/2016	11/06/2016	Test RC car obstacle detection and autonomous control interfaced with Sensor Module over CAN	Not started
5	11/07/2016	11/13/2016	Interface GPS module with Master Controller	Not started
6	11/14/2016	11/20/2016	Interface Android/Bluetooth module with Master Controller.Test Waypoint System	Not started
7	11/21/2016	11/27/2016	Debug any issues with Master controller and other modules	Not started
8	11/28/2016	12/12/2016	Final debug/testing of RC CAR	Not started

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

Discuss your hardware design here. Show detailed schematics, and the interface here.

Hardware Interface

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

Software Design

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.

Implementation

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

Testing & Technical Challenges

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

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

My Issue #1

Discuss the issue and resolution.

Conclusion

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

Project Video

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

Project Source Code

• Sourceforge Source Code Link

GitLab

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