ECE 4760 Lab 4 Report Introduction

ukrainianlegalElectronics - Devices

Nov 2, 2013 (3 years and 7 months ago)

56 views

Ned Bingham

eab242@cornell.edu

Nicholas Kramer

nak54@cornell.edu

ECE 4760 Lab 4 Report

Introduction


The goal of this lab was to create a PID motor controller using the Atmega644 MCU, an LED, a
phototransistor, a JFET transistor, an opto
-
isolator, a couple capacitors, and an analog to digital
converter.


Design and Testing Methods


Our hardware design met
hodology involved breaking the system into many modular chunks, testing
each subsystem individually, and then testing the system strung together. By splitting the system into
small manageable tasks, we avoid the combination of many small problems that turn

into one massive
system that is hard to debug. Our system was broken into four primary components of our hardware,
namely the light gate, the Schmitt trigger, the opto
-
isolation, and the motor driver.


For the blade detection, we decided to use a light ga
te design. This involves an IR LED which is pointed
through the gaps of fan blades to an IR phototransistor on the other side. Every time a blade comes in
between the light gate, the node at the phototransistor drops voltage. This design was chosen because

it would allow for seven high to low transitions per a fan revolution (as there were seven blades), and let
us take advantage of the precision of the fan's engineering instead of relying on us precisely painting fan
blades with whiteout like other groups
were. We were initially getting very low gain on our
phototransistor, and the difference between light being blocked and light passing was only about
200mV. We could have tuned the comparator circuit to have a precise threshold, but from a theoretical
stan
dpoint it seemed that we should be getting much higher gains. After tracing the voltages at every
node, we identified that the issue was because the terminals of the phototransistor were swapped. The
device is not symmetric and so having the emitter and co
llector swapped was very harmful. With the
correct circuit, a light gate design results in about a two volt jump between high and low.


We needed to turn this two volt jump into a binary signal for our microcontroller. This is obviously done
through a com
parator. The comparator we chose is the Schmitt trigger as it has hysteresis. Hysteresis is
very important for our design, as the phototransistor is very sensitive to noise. Were it to fluctuate
around the transition voltage, the comparator would output ma
ny high to low spikes instead of a clean
transition. Through trial and error with potentiometer resistor dividers as the inputs, we decided on a
feedback resistor of about 1MOhm. This subsystem was easily debugged.


The next system we built was the opto
-
i
solation. It is vital to have isolation between the motor and
microcontrol
ler
. If the motor is in any way being driven by the microcontroller, the microcontroller could
source too much current and fry. If they share a ground, ground
-
bounce from the large t
ransients
motors produce can reset the microcontroller without warning. The opto
-
isolation unit we used was the
4N35. By sending the control signal through light instead of voltage, we assure the signal is completely
electrically isolated. After a little d
ebugging with the voltmeter (we thought there was a break where
there wasn't one), we managed to have complete isolation tested by measuring the resistance between
the two grounds as nearly infinite. A 5v control signal on the input would create a 12v outp
ut.


Finally, we built the motor driver. Using the 12v output from the opto
-
isolator, we activated the circuit
shown in our documentation. These subsystems had no problems. We combined the subsystems, and
only minor tweaking such as comparator threshold vo
ltage adjustment was required.


The software system was also broken up into subtasks, allowing us to not only take advantage of
modularity, but also the multitasking kernel Tiny Real Time. A logical division of labor was splitting our
program into three t
asks: the LCD control, the serial interface, and the actual PID loop. Semaphores
were used to manage shared variables. Our shared variables were desired speed (shared between the
serial interface, LCD, and PID control), actual speed (shared between PID con
trol and LCD), and PID gains
(shared between serial and PID).


The serial task used fgets and fprints to interact with PuTTY through serial. A basic parser could read
variables and set values of s (desired speed), as well as p, i, d, (PID gains). We also
added an o variable
that could be set by serial, which serves as a constant offset. For debugging and fine tuning, we also
implemented a g function which would output to serial all of the current gains, and an e function which
would print the average error

over the last nine samples.


The LCD task was responsible for refreshing the LCD values at approximately 5 times a second. This has
been done in every lab so far and so was mainly recycled code.


The final task was the PID controller. This task measured the current frequency using the same
frequency detection algorithm from lab 2, and then calculated the proportional, integral and differential
gain. We used our total PID error as negative feedback
to force the motor to the set RPM.


As is extremely rare in engineering, the code worked with only a few bugs and interfaced beautifully
with the hardware. The only thing left to do was fine tune PID gains. This is easier said than done. We
used gradient
decent to get the three values p, i, and d. We started with two random sets of values, and
then moved in the direction that guaranteed a smaller error. Eventually we reached a minimum error
where no matter what direction we took the values, the error still

increased. The minimum we
found
was at p=50, i=0.1, d=30.


Documentation


Figure
1

Motor Driver

1 M Ohm


Figure
2

Speedometer


Results


At a set speed of 1000RPMs or higher, this resulted in an error
that oscillated from 20RPH to 50RPM
with the average being on the order of 30RPM. For lower values, the error averaged around 40RPM.

Our
system had a decay time constant (time to go from full value to 3/8 of the full value) of 0.098
seconds.
This decay con
stant measured the time it takes for the motor to turn

off. Our system stabilized to a new
value in 1.013 seconds. This was measured from the time a new speed command was detected to the
time that the motor falls below the new RPM after overshooting it. Wh
ile measuring error, we noticed
that our system was creating a lot of ground bounce. Our system was pulling more current than our
power source could handle. This could be increasing our error drastically and causing the errors of 40
and 30 that we see belo
w. This is shown in Figure 5.



RPM

Error

500

40

1000

30

2000

30




Figure
3

Motor Decay Time Constant



Figure
4

System Stabilization Time












-0.20
0.00
0.20
0.40
0.60
0.80
1.00
1.20
1.40
1.60
0
0.5
1
1.5
2
2.5
Decay

-0.50
0.00
0.50
1.00
1.50
2.00
2.50
3.00
3.50
4.00
0
0.5
1
1.5
2
2.5
Growth

Ground Bounce



Figure
5

Ground Bounce

Conclusions


Our PID controller was very usable
. It had an easy interface and

five useful commands. p #, i #, d #, and s
# set the parameters proportional gain, integral gain, differential gain, and desired speed. g displayed all
of the gai
n values and e displayed our current average error. If we had the chance to do it over again, we
would have budgeted for time for tuning. This would have allowed us to have a more accurate pid
controller overall.