# 2018FallTeam4

## Encoder Project Introduction

Our project involved adding an encoder component to the MAE 148 Autonomous Vehicle we previously built. The motivation for this project was to have access to data concerning the speed and distance travelled in order to improve speed control.

The original configuration of the vehicle controlled the speed of the car by controlling the voltage from the battery to the motor. This voltage was based on data from user inputs(explain in step 1). The encoder allowed the voltage to be based on data concerning the actual current speed, giving the vehicle could have cruise control capability.

## Team Members

Selina Wade

Torin Halsted

Sepehr Foroughi

Hoang Thai

## Process

### Step One: Build the Autonomous Vehicle

*Parts*

Acrylic Board: We used calipers to measure the dimensions of the mounts on our base and then laser cut an acrylic board with holes to mount our 3D printed camera mount.

Camera Mount: We designed and printed a mount to hold the camera at the appropriate height and angle to capture the track. We also included a slot to pass the cord band through without damaging it.

RPI Holder: We 3D printed a small piece to hold the RPI on our car.

Wiring Schematic: We clearly documented our wiring (right).

*Using RPI*

*GPU Training*

*Autonomous Success*

### Step Two: Mount the Encoder

We used an optical quadrature rotary encoder with a resolution of 600 pulses per revolution. This encoder produces two square wave outputs which can be used to determine the distance, speed, and direction that the encoder is is turned.

### Step Three: Ardiuno Communication

As stated before, the encoder that we used sent 600 pulses per revolution. This resolution is amplified by gear ratio so every turn of the wheel causes approximitely three revolutions of the encoder. Additionally, for each pulse from the encoder, four readings can be taken (at the up phase and down phase of each swquare wave). Therefore, the encoder records 27400 data points per meter travelled, meaning at a maximimum velocity of approximately four meters per second, it records at 109.6 kHz. Meanwhile, the Raspberry Pi used for the remainder of our car controls runs its code at only 20 Hz. For this reason, we could not use the Raspberry Pi to directly read the response from the encoder. Instead, we used a Arduino Uno board to read and count the pulses of the encoder, then calculate the distance travelled and current velocity before sending this information over serial to the RPI and an LCD display at a rate of 20 Hz.

When connecting the encoder to the Arduino, we used the digital pin inputs and configured Arduino's built-in pull up resistor. Then, we wrote a code using the attachInterrupt function to signal a change whenever either the A or B phase signal went changed from HIGH to LOW or LOW to HIGH voltage. This ensured maximum resolution and accuracy because the interrupt saves time and ensures that signals are not skipped.

Once the Arduino code was working we calibrated it manually by driving the car 1m ten times and recording then averaging the number of counts the Arduino recorded to find a value of 27400 counts/meter, which gaves us an accuracy of 0.0365mm.

### Step Four: MATLAB Simulation

#### Creating a Proportional Model

The purpose of having an encoder on our car is to create a closed-loop feedback system to control the velocity of the vehicle as it drives. Prior to installation of the encoder, velocity was controlled indirectly via the throttle, or pwer provided to the motors from the PWM. However, environmental variables such as the slope of the road, changing friction, or other disturbances make this method of velocity control inaccurate. The car will clearly need more power to maintain its speed while driving up a hill but because it cannot sense the slope of the road it is on, we must instead create a closed-loop system where we measure the car's actual velocity and compare it to the goal velocity, then use this error to adjust the throttle.

Initially, we started basic to come up with a formula for proportional control. We first calculated the approximate Gain value G, defined by v(t)=G*T(t), where v=velocity (m/s) and T(t)=throttle (range 0-1). At full throttle, our car has a maximum velocity of approximately 4 m/s, so we set the gain to G=4. Then, we needed to develop a value of Kp for the equation T(t)=Kp*e(t), where e(t)=SP-v(t) and SP is the "set point" or desired speed of the car. The maximum e(t) could be would be if we set SP to the maximum velocity and started the car from rest, in which case e(t)=4 m/s. Therefore, in order to not exceed a throttle of 1, we set Kp=1/4, which means Kp=1/G. However, with only using this equation of proportional control, the car rises and settles to a velocity of SP*KG/(1+KG)=SP/2. While this could be easily solved by using a SP value of twice our desired speed, if another steady disturbance arose the proportional control would not be able to correct this persisting error. Therefore, to increase the stability of our control system, we decided to add in integral control.

When using PI control, instead of finding the throttle simply by multiplying the error by a gain Kp, we used this value to adjust the previous throttle value with each loop of the program. Therefore, instead of T(t)=Kp*e(t), we used the equation T(t)=Kp*e(t)+T(t-1). This change stabilized the system so that even with large disturbances, the velocity would settle to the SP value without causing amplifying oscillations.

To be sure that this equation would work the way we had hoped, we decided to model the system using MATLAB. Like our Raspberry Pi program, MATLAB runs in discrete time, not continuous, which makes it a good model to use. We created the program so that with each loop the program would calculate the new throttle using the equation T(t)=Kp*e(t)+T(t-1). However, when modelling the motion we incorporated a delay of one loop, or 0.05 seconds, before the new velocity takes effect because in our real life system the arduino only updates the RPI with the encoder data at a rate of 20 Hz. Additionally, we programmed in random disturbances to the velocity to be simulate environmental factors and show that our control would allow the car to correct for these disturbances. Finally, to verify the value of Kp we calculated before, we created code to simulate the car's response 10 times at 100 different Kp values between 0 and 1 and then pick the one which returned the smallest squared error. The MATLAB code confirmed that the Kp value should be approximately 0.25, or 1/G.