Download Final Report - WordPress@UP

Final Report
Shiley School of Engineering, University of Portland
EE/CS 481A Senior Design Project
Magnetic Manipulator
Team 125
Chad Perkins (Spring Team Lead), John Olennikov,
Marley Rutkowski (Fall Team Lead) Benjamin Younce
Faculty Advisor: Dr. Robert Albright
Industrial Advisor: Andy McConnell
Client: Dr. Mark Utlaut
March 28th, 2014
2
Table of Contents
Introduction
……….…………………………………………… 3
Technical Outcomes
……….…………………………………………… 4
1-Arduino Microcontroller
……….…………………………………………… 5
2-Computer
……….…………………………………………… 8
3-Transistor Circuit
……….…………………………………………… 9
4-Electromagnet
……….…………………………………………… 10
5-Levitating Object
……….…………………………………………… 10
6-Hall Sensors
……….…………………………………………… 10
7-Hall Sensor Processing
Circuit
……….…………………………………………… 11
8-Enable Switch
……….…………………………………………… 11
9-System State LEDs
……….…………………………………………… 12
10-Power Source
……….…………………………………………… 12
Process Outcomes
……….…………………………………………… 12
Assumptions
……….…………………………………………… 12
Product Changes
……….…………………………………………… 13
Milestones
……….…………………………………………… 14
Risks
……….…………………………………………… 14
Conclusion
……….…………………………………………… 15
Appendices
……….…………………………………………… 16
Appendix A: Milestones
……….…………………………………………… 16
Appendix B: Circuit
Schematic
……….…………………………………………… 18
Appendix C: Arduino Code
……….…………………………………………… 19
3
Introduction
Electromagnets have been used for a variety of different purposes, ranging
from picking up paper clips using a wire wrapped around a nail to MRI scanning and
even magnetic levitation transportation systems. The Magnetic Manipulator project
adds to the list by using an electromagnet controlled by a microcomputer to levitate
a permanent magnet and move it up and down in the air.
The project began with research into the components that were required to
levitate the magnet. This included a solenoid, two Hall sensors, and a
microcomputer. Once the components arrived, the solenoid was tested to ensure
that it would generate a strong enough magnetic field to levitate the magnet. Next,
an Arduino microcomputer was used to generate a pulse width modulation (PWM)
signal. The output from the Hall sensor was tuned in order to increase the precision
of the values that Team 125 needed and to remove unnecessary outlying values.
Next, in order to further increase Hall sensor output precision and have more
processing power, the code was ported from the Arduino Uno to the Arduino Due.
Using the Hall sensor output to the Arduino and a PID algorithm, the Arduino Due
has been able to levitate the magnet for an indefinite amount of time. Figure 1
shows the finished Mag-Lev stand.
Some challenges faced with the circuit were increasing the precision of the
Hall sensor outputs, and reducing noise. Another anticipated challenge was that our
breadboard could not handle the amount of current we were sending through it, and
would melt. The biggest challenge with the Arduino was porting the code from the
Uno to the Due. The greatest difficulty in the porting process was finding
documentation to implement the features that existed in the Uno, using the Due. The
team was surprised with the sources of noise in the circuits and the lack of
documentation for the Due. Team 125 did very well in figuring out the circuits for
tuning the Hall sensor output and troubleshooting the sources of noise in the circuit.
The difficulties in porting the code from the Uno and Due could have been taken
care of faster if more research was done into the documentation of the Due.
Fig 1. The Finished Mag-Lev
4
This report begins with the technical outcomes of the project. It then
discusses the Arduino code and the different processes that control the PWM, read
Hall sensor values, and send data to the Processing code. The computer and
graphical user interface (GUI) sections talk about the components of the user
interface and describe how the Processing code interacts with the Arduino. Each
physical component is described in its function and how it contributes to the result of
levitating the magnet. Next, the assumptions and changes to the project that the
team made over the past six months will be addressed. The progress of the MagLev project is described using the milestones, and is followed by a summarization of
the risks, what went wrong and what did not. Finally, the paper is summarized with a
conclusion.
Technical Outcomes
Overall, the Magnetic Manipulator system was designed as planned in the
Requirements and Functional Specifications report. The only system component that
was not included in the final product from the original design was the power
regulator. This was because the component did not work as planned because of low
quality parts and a bad design by the manufacturer. Since laboratory supplies were
used as the power source instead, no additional regulation was needed.
Additionally, an electromagnet monitoring circuit, a Hall sensor processing circuit,
and some system-state LEDs were added. The primary components of the Mag-Lev
are as planned in the original design as follows: Arduino, computer, electromagnet,
Hall sensor, levitating object, power source, power transistor, and an enable switch.
Figure 2 is a block diagram that depicts each of the major system components and
how they interact with each other. Detailed descriptions of each component are
found below.
Fig 2. System Block Diagram
5
1-Arduino Microcontroller:
The Arduino microcontroller is the central brains of Team 125’s system. It is
responsible for interpreting commands from and providing information to the user,
tracking the levitation of the magnet through the Hall sensor, and controlling the
power given to the electromagnet via the transistor.
 Input data from the user is received by the Arduino as bytes sent over a serial
cable by the computer. When commands are available in its buffer, the
Arduino reads in and interprets them in order to determine how the state of
the system should be affected.
 System state data is encoded by the Arduino and sent over serial cable to the
computer in order to provide the user with information to improve system
control.
 Processed Hall sensor data is read in by the Arduino on an analog pin and
interpreted in order to track the position of the levitating object at any given
time.
 Position data is interpreted by the Arduino in order to determine the how to
control the electromagnet, given the current position of the levitating magnet
and its desired position. A proportional-integral-derivative (PID) control
algorithm is used to determine the percent duty cycle of the pulse width
modulation (PWM) signal needed to keep the levitating object at (or get it to)
the desired setpoint.
Arduino Code Overview:
This section gives a brief overview of the key characteristics of the Arduino
controller code. This includes the system state machine structure, PWM generation,
and the Hall data analogRead.

State Machine:
The primary structure of the Magnetic Manipulator code is that of a state
machine. After initializing, the system is always in one of four modes:
MODE_CALIBRATE, MODE_IDLE, MODE_PID_CONTROL, or MODE_OFF. The
state machine is illustrated in Figure 3, followed by descriptions of each state.
6
Fig 3. System State Machine

MODE_CALIBRATE:
After initialization the code it is set in this state. The system can also be set
into Calibration Mode if a recalibrate command is received, in which case it begins
calibrating regardless of what mode it was previously in. In order for Calibration
Mode to run properly, no object should be near the levitation area. In this mode the
system first sets the coil PWM duty cycle to zero. It then continues increasing the
duty cycle by small increments (defined by a system constant), taking many samples
of the magnetic field strength at each level and storing them in an array of calibration
values. These values are later used to find the duty cycle necessary to achieve a
given field strength (varies based on the small changes in the input voltage and thus
may not always be the same). The Calibration Mode is complete once it reaches a
full duty cycle and the array of calibration values is full. At this point, the system
switches to Idle.

MODE_IDLE:
In Idle Mode, the system is simply waiting for a levitation object to come into
range. In this mode the system sets a default PWM duty cycle in order to orient any
object that comes close, and then it waits. Once an object enters the initialized
control interval, the system switches to PID control.

MODE_PID_CONTROL:
PID Control Mode is the primary state of the system in which it levitates an
object in the sensor’s range. In this mode, the system updates the PWM duty cycle
at a frequency of 1kHz. Each time it updates the new duty cycle is determined based
on a PID control algorithm, which uses a current error term (P), an integral term (I),
7
and a derivative term (D), each with a different weight to determine what the new
PWM duty cycle should be in order to keep the levitating object at the current set
point. This algorithm works such that if the object is below the setpoint, the new field
strength will be greater, and it will be less if it is above the set point. If while in PID
Control Mode, the object gets too close to the Hall sensor, the system will switch to
Off Mode. If the object gets too far away, it will go back to Idle.

MODE_OFF:
This mode is reached if the levitating object has gotten too close to the MagLev’s electromagnet. When in this mode, the electromagnet is turned off so that the
object is not sucked up too high and permanently attaches to the soleoid. The
system stays in Off Mode until the magnet gets within a defined tolerance of the
current set point at which time the system is switched back into Control Mode.
PWM Generation:
The PWM signal is essential in order to modulate the voltage to the
electromagnet in an analog fashion using the digital Arduino system. The standard
PWM functions provided by Arduino did not provide the frequency customization nor
the duty cycle percent precision that was required by this project. Thus, it was
necessary to utilize the PWM macrocell onboard the ARM CPU. Once initialized by
manipulating control bits, this macrocell produces a PWM signal at a constant
frequency without any need of CPU time. The duty cycle percent is then
manipulated by the system code by simply adjusting a 16 bit timer value (thus there
are 2^16 possible PWM percentages).
Hall Data AnalogRead:
Due to system noise and ADC (analog-to-digital-converter) inaccuracies,
performing a normal 12 bit analog read, when information on the current Hall signal
value was needed, proved not to be accurate enough for the system. Therefore, two
separate smoothing techniques were utilized in order to improve the data by
averaging over space and time. These techniques were keeping a moving mean
over time and running multiple ADCs synchronously.

Synchronous ADCs:
Normally in Arduino, one uses the analogRead method to get a digital
representation of a analog signal. When a system calls the analogRead method the
system triggers an ADC to start an analog read, and waits until it is done (a process
that takes a number of CPU cycles). At this time it receives one value and continues.
In normal applications the time this takes is not a problem. However, when readings
are being taken on the order of 100kHz (as is the case in this project), the fact that
the CPU time to data throughput of this process of simple analogRead is relatively
8
high will significantly bog down the system. In order to increase the data/CPU time
ratio, a system timer was set to trigger at 100kHz. Eight ADCs connected to pins A0A7 are triggered to automatically start converting synchronously on every clock
trigger without the need of any intervention by the CPU. Once the ADC on channel 7
is finished converting, it triggers a system ISR (interrupt service routine) that collects
the data from all 8 ADCs.

Moving Mean:
In order to average values over time, the system keeps a moving mean. It
does this by always maintaining a sum of the 10 most recent Hall values produced
by the ADCs (note the average of all 8 ADCs is considered one value). Every time
the data from the ADCs is retrieved, the oldest value currently in the moving Sum is
subtracted off. The new value is added in and stored in a circular array so that it can
be subtracted off again once it is too old.

Retrieving Values:
Both the synchronous ADCs and the moving mean are always running on the
system, whether or not a reading is needed at that time. When a when the system
does need a value, all it needs to do to get an average of 80 samples is divide the
current moving summed value by 10.
2-Computer:
The laptop (or desktop) computer serves as the user interface for the
magnetic manipulation system. The Arduino and the Processing code setup a
connection using a handshake system. That way, both sides can ensure that they
are in sync and can understand one another. The user is able to input commands
into the GUI which are encoded and sent over serial cable to the Arduino to be
processed. Even though this has not been tested, the GUI app has to buffer
commands to make sure that they are not sent too fast for the Arduino to read
because of the serial queue size limit in the Arduino. Because the GUI runs on a
computer, it has more processing power for data crunching and formatting.
Therefore, to reduce the load on the Arduino, it only sends raw data to the GUI.
GUI Code OverView:
In order to make it easier to understand what is going on in our system, the
Arduino sends data to the team’s Processing code, which formats and displays the
data to the user. The Processing programming language was selected because that
was the language that Marley had previously used to interface with the Arduino. The
Graphical User Interface (GUI) is composed of buttons, labels, text fields, and
graphs. Figure 4 displays the GUI that the team ended up with. Since all of these
9
components use some of the same fields (x and y coordinates, height, width, etc),
the object-oriented programming (OOP) methodology was selected over functional
programming. As a result, changing layout, formats, and colors for the elements is
greatly simplified.
The GUI initially was just going to be three labels with pulse frequency,
magnetic field strength, the calculated object distance and two buttons to raise or
lower the magnet. A console was later created to display data from the Arduino, and
to manage the serial connection. In order to understand the PID algorithm, a graph
was also included to graph the PWM, and the PID values, respectively. Because
visual data is often much easier to understand than textual data, we are considering
modifying the GUI in order to include multiple graphs to plot the permanent magnet’s
position and the values of the PID algorithm.
Currently, the Arduino waits for the handshake from the Processing code in
order to start its execution. However, because the purpose of the GUI is for
formatting and displaying data, the GUI is not an essential component that is
required to levitate the object.
Figure 4. The Mag-Lev GUI
3-Transistor Circuit:
A transistor is necessary to control the power to the electromagnet provided
by the power source. The power transistor is not controlled by a digital control
signal, as originally envisioned, but rather by a high frequency PWM signal from the
Arduino. As the duty cycle of the PWM signal is adjusted, the transistor effectively
increases or decreases the voltage across the electromagnet.
For this project a TIP 120 Darlington pair transistor is used. The base of the
transistor is wired to the Arduino PWM signal through a 1kΩ resistor so that there is
a current to enable the transistor. The transistor is wired such that when it is
10
enabled, it connects the ground of the electromagnet to the ground of the power
source so that the coil is energized. When the transistor is off, the electromagnet is
not grounded and therefore no current can flow through it. Therefore, the negative
lead of the electromagnet is attached to the collector of the transistor and the emitter
of the transistor is wired to ground.
Additionally, diodes are wired with their anode connected to the collector of
the transistor (and the negative lead of the electromagnet), and their cathode
attached to the incoming power (and the positive lead of the electromagnet). This is
done so that any back-voltage created by the electromagnet when its power is cut
will be shorted back to the power supply, rather than creating a backward surge in
the circuit which could possibly damage the transistor and/or Arduino. The transistor
circuit also features an LED (with resistor to control current flow) that is attached to
the incoming control PWM signal and serves to indicate the present state of the
transistor. The brighter the LED is the higher the present duty cycle of the PWM.
4-Electromagnet:
The electromagnet creates the magnetic field that interacts with the levitating
object, keeping it in place. It is activated and deactivated by the transistor that
controls the power provided to it. As the duty cycle of the transistor (based on the
PWM sent to it) is increased, the strength of the field of created by the
electromagnet also increases.The strength of the field created by the electromagnet
is reflected in the voltage outputs of both Hall sensors.
5-Levitating Object:
The objective of Team 125 is to levitate a small object, weighing 5-10 grams.
The team designed the Magnetic Manipulator to levitate a 1/2 x 1/8 inch disc
neodymium magnet.
6-Hall Sensors:
Hall sensor data is used to gather information on the position of the levitating
object. A Hall sensor varies its output voltage in response to the magnetic field it
senses and the Arduino monitors this data as an analog input. The Hall sensor
outputs a voltage between 0V and 5V. A voltage of 2.5V indicates no magnetic field,
voltage below 2.5V indicates a negative field (magnetic field lines going down
through the sensor), and a voltage above 2.5V indicates a positive field (magnetic
field lines going up through the sensor). The magnitude of the Hall sensor value
difference from 2.5V is proportional to the strength of the magnetic field present with
sensitivity of the sensor at 5mV/G (millivolt / gauss).
A. The primary Hall sensor is positioned at the base of the electromagnet
such that it is between the electromagnet and the levitating object. Therefore, the
output of the Hall sensor at any given time contains information on the present state
of the coil, as well as the proximity of a levitating object. As a levitating object gets
11
closer to the Hall sensor, the field it creates at the point of the Hall sensor
increases. From this information the Arduino is able to interpret the position of the
levitating object at the present time.
B. Another Hall sensor is placed at opposite end of the electromagnet (on top)
so that it measures the strength of the field produced by the electromagnet, but is
not affected by an object in the levitation area. The value of the electromagnet Hall
sensor is subtracted from that of the primary Hall sensor in order to give a value
representative of just the magnetic field produced by the levitating object.
7-Hall Sensor Processing Circuit:
The Hall sensor processing circuit was an addition from the system’s original
design. This circuit takes the signals from both Hall sensors and processes them to
create a more useful signal for the Arduino. There are two separate processing
circuits which provide signals for different stages of the system, and the Arduino can
choose between these signals using a multiplexer controlled by the Arduino’s digital
output pins.
The first signal processor provides a signal for system calibration
measurements of the strength of the magnetic field at a given PWM duty cycle. The
Hall sensor’s voltage is between 0V and 5V and the Arduino Due can only handle up
to 3.3V so this circuit first uses a voltage divider to reduce the maximum voltage to
3.3V. Since for this project there should never be a negative magnetic field (Hall
value less than 2.5V) this processor next subtracts 1.6V from the signal so that
positive voltages only represent positive fields. Finally, it amplifies the signal back up
so its maximum of 3.3V.
The second signal processor provides a signal optimized for general system
operation. This processor subtracts the electromagnet Hall sensor value from the
primary Hall sensor value using an operational amplifier, effectively removing all
information about the present field strength of the electromagnet from the signal.
Therefore, the signal only represents the magnetic field from the levitating object.
This processing circuit is an alternative to the software subtraction of the
electromagnetic field strength using a calibrated value which was originally planned,
but caused problems when there was magnetic flux. The signal processor takes the
subtracted signal and amplifies it to a range of 0V to 3.3V before passing it on to the
Arduino through a multiplexer, which gives the Arduino more reliable information
about the levitating object than before.
8-Enable Switch:
A physical two-state switch can be used to enable and disable the levitation
system. The switch is connected to one of the Arduino’s digital input ports. When
disabled, the electromagnet has no power supplied to it. When enabled, the system
will work as specified.
12
9-System State LEDs:
Three LEDs which are used to indicate the current state of the system at a given
time were a useful addition to the original design. They are each individually
controlled by a digital signal from the Arduino which triggers a transistor to power the
LEDs from the external 5V power supply. The state indications and their meanings
are displayed in Table 1.
Table 1. LED States
Red
Yellow Green
Waiting for Serial
ON
ON
OFF
Calibrating
ON
ON
ON
Idling
OFF
ON
OFF
Stopped
ON
OFF
OFF
PID Control
OFF
OFF
ON
10-Power Source:
The primary power source provides the energy necessary to activate the
electromagnets. It was originally planned to use a single external power AC/DC
converter regulated by a regulator to power the system. However, the power
regulator purchased did not function as anticipated and sources of different values
were required to power the Hall Processing circuit. Therefore, a single laboratory
supply with both sources in parallel set at about 7.5V is used to provide the power
for the electromagnet. This supply can provide up to 6A of current. A second
laboratory supply is used to provide +15V and -15V sources to power the op amps in
the Hall processing circuit. This supply is also used to provide a 5V source for the
system state LEDs. Each of these three sources can provide up to 3A if required.
However, nowhere near this amount of current is necessary for their application.
Process Outcomes
Assumptions
The assumptions of Team 125 were essentially the same at the beginning of
the project as they were at its conclusion, with a few exceptions. The assumption
that two dimensional levitation would be achievable in two semesters did not hold
true. This caused the group to rethink its main goal of the design project and decide
to create stable one dimensional levitation instead of levitation with control in two
13
dimensions. Another assumption the group made that did not hold true was that the
Hall sensor would give accurate values. Unfortunately, the Hall sensor sent a value
in a range that needed to be redefined in order to be read accurately by the Arduino.
This was a setback, but Team 125 was able to work around it. Other assumptions
proved true, such as the assumption that the solenoid that was selected had the
strength to levitate a magnet two inches below it. The electromagnet works perfectly
and was definitely the right choice for the job. Another assumption that was correct
was that an Arduino Due would be necessary for interpreting the Hall sensor data
because of its processing power and speed. Prototyping was performed with an
Arduino Uno and the team found that it did not have enough power to perform the
necessary operations.
There are some assumptions that were not in Team 125’s Functional
Specifications, but should have been. For example, the team should have expected
there to be some noise from the circuit leaking into the negative feedback system
that would interfere with stable levitation. In addition, the team could have assumed
that it would be necessary to use a permanent circuit board instead of a solderless
breadboard because of durability and noise problems. Finally, the last assumption
that was not on the Functional Specifications report was the assumption that the
project would use more than one power supply, making it difficult to transport the
project. These are complications that arose during the construction of the project
that could have been accounted for but were not, and ultimately used up a lot of
time.
Product Changes
There are many differences between the plan the group started with for the
Mag-Lev project and the plan at its conclusion. As the project progressed, many
changes have occurred in order to ensure that the magnetic levitation device would
be completed on time. The most important change that had to be made was to throw
out the idea of two dimensional control because of the complexity of one
dimensional levitation using a digital system. This change happened in the middle of
Fall semester. It affected the finished product because the Mag-Lev is not as
complex as originally predicted. It could have been caught earlier with better
planning and a better understanding of digital systems. Another tweak that Team
125 made to the design of the Mag-Lev was to add a resolution enhancement circuit
to the output of the Hall sensor mounted underneath the solenoid. This was made in
the beginning of Spring semester because the Arduino was not getting reliable data
from the Hall sensor. The result of this upgrade was that the Arduino got more
accurate data from the Hall sensor and the levitation of the magnet was more stable.
This could have been caught earlier by thinking about the accuracy and feedback
needed in order to make the levitation more stable.
Other hardware additions include a second Hall sensor on top of the solenoid
in order to get a read of its magnetic force, and an RC filter circuit in order to reduce
the noise of the input voltage, which messes up the Hall sensor output. These
changes both occurred in mid-March. Additionally, Team 125 had to find a suitable
14
heat sink for the power transistor used to turn the electromagnet on and off because
it heated up too much.This could have been prevented by purchasing our own heat
sink and realizing that transistors can heat up when turned on and off rapidly. After
implementing the heat sink update, the transistor has not had any further problems
with overheating. The team has also implemented modifications to the GUI that
deviate from the original plan because of previous changes to the design, such as
adding a graph that displays the position of the levitating magnet and removing the
2D interface. These changes made to the design of the circuit allowed Team 125 to
finish on time and with a working project.
Milestones
The milestones (see Appendix A - Milestones) that were set at the beginning
of this project were intended to keep the team on track and ultimately finish the
project on time, and they did just that. Almost all milestones were met or exceeded
during the Fall semester. For example, the Requirements and Functional
Specifications report and the Design Document were both submitted on time. The
budget and prototype plan were also completed on time. Team 125 ordered parts
before December 6th, 2013, so that milestone was completed early. Unfortunately,
as Spring semester began milestones started getting missed for weeks, such as the
prototype build being 100% complete, because of problems with noise and
inaccurate Hall sensor values. These caused the group to implement some of the
changes mentioned earlier in this section, such as a Hall sensor resolution circuit
and an RC filter circuit to reduce noise. The group originally planned to have one
dimensional levitation working by February 21st, but that did not happen because of
complications with switching code form the Arduino Uno to the Arduino Due and
inaccurate Hall sensor outputs. These milestones have generally kept Team 125 on
track since the beginning of the academic year and have been one of the reasons
that the project will be completed on time.
Risks
Some of the risks that were planned for happened, and some did not. The first
risk that was planned for was that parts that the team ordered would not get to the
school in time. This fear turned out to be unfounded, as all parts that were ordered
were at the school by the beginning of Spring semester. The next risk listed in the
Functional Specifications report was that the solenoid the team ordered would not
be strong enough to levitate the magnet that was chosen. This, too, did not occur.
One risk that was planned for did occur: two dimensional movement turned out to be
much harder than the team had anticipated. So hard, in fact, that Team 125 did not
reach two dimensional movement at all. The contingency plan worked; the team
decided that if two dimensional movement was too hard, the focus of the project
would turn to one dimensional levitation instead. Another risk was that the Arduino
Due or Hall sensor would not be able to process the information as fast or accurately
15
as required. This occurred because the Hall sensor output needed to have more
resolution. The team was able to get away with implementing a fix instead of
ordering new parts. The last risk that Team 125 planned for and occurred was that a
part malfunctioned or broke. Team 125 bought two voltage regulators of the same
type, from the same company, for a power supply. They did not work because of
poor quality. These parts were necessary for creating a custom power source, but
instead of ordering more low-quality parts, the group decided to use some power
supplies from the senior design laboratory. This was a low-cost fix that allowed
Team 125 to continue construction and testing of the prototype without losing time.
The rest of the planned risks were incorrect schematics, insufficient laboratory
space, sickness of a team member, and a broken prototype. None of these risks
occurred.
One problem that occurred, but was not accounted for, was a couple of snow
days in early Spring semester that prevented the group from working together. This
slowed down testing and debugging of the circuit and was a contributing factor to
Team 125 missing the “Prototype 100% Complete milestone”. This should have had
a contingency plan that involved meeting again at a later date or redistributing tasks
to people who were able to come in to work on the circuit, which would have
minimized or prevented losing time. Overall, Team 125’s contingency plans were
effective when necessary and helped the team finish the project on time.
Conclusion
Team 125 has developed a system that will achieve stable magnetic
levitation. All objectives have been accomplished except for two dimensional control,
because of the complexity required to design the system. When developing Team
125’s system, the team faced lots of trial and error testing in order to develop the
code to make the device work properly. Therefore, one of the team’s biggest
challenges was testing the Magnetic Manipulator, and the potential of accidentally
damaging system components was present throughout the trial process. To improve
design in a future project, two Hall sensors should be used, one above and one
below the electromagnet. This allows for greater accuracy that Team 125’s design
lacked until near the end of the project. Although the team’s ultimate goal of 2D
magnetic manipulation was a stretch on the skills of each team member, the
members of Team 125 are proud that they provided themselves with goals of
increasing difficulty and achievable milestones that led to the ultimate success of the
Magnetic Manipulator.
16
Appendix A
Milestones (Fall Semester 2013 and Spring Semester 2014)
Note: Major Milestone deadlines and descriptions are indicated in bold.
Due Date / Date
Completed:
Description:
Type:
Fri 13 Sep / Fri 13
Sep
Complete Initial Draft of All Sections of the
Functional Specifications
Minor
Fri 20 Sep / Fri 13
Sep
Complete Functional Specifications, first complete
draft (ver. 0.9)
Minor
Fri 27 Sep / Fri 27
Sep
Complete Functional Specifications, advisorapproved draft (ver. 0.95)
Present September Program Review
Minor
Minor
Fri 04 Oct / Fri 04
Oct
Complete Functional Specifications, final draft
(ver. 1.0)
Major
Fri 11 Oct / Fri 11 Oct
Create Parts List, to include pricing and sources.
Minor
14 Oct-18 Oct
Fall Break
Fri 25 Oct / Fri 25 Oct
Present October Program Review
Create initial budget
Determine lead times for parts and create an
ordering schedule accordingly.
Minor
Minor
Minor
Fri 01 Nov / Fri 01
Nov
Complete Design Document, first complete draft
(ver. 0.9)
Minor
Fri 08 Nov / Fri 01
Nov
Complete Design Document, advisor-approved draft Minor
(ver. 0.95)
Minor
Complete Final Budget Draft
Fri 15 Nov / Fri 15
Nov
Complete Design Document, final draft (ver. 1.0)
Complete Final Budget
Major
Major
Fri 22 Nov / Fri 22
Nov
Create initial plan for prototype build.
Minor
28-29 Nov
Thanksgiving Break
17
Fri 29 Nov / Fri 29
Nov
Present November Program Review
Minor
Fri 6 Dec / Fri 6 Dec
Finalize prototype plans
Determine lead time for any technician help.
All parts purchased or ordered
Minor
Minor
Major
13 Dec-10 Jan
Christmas Vacation
Fri 17 Jan / Fri 17 Jan
Begin programming for Arduino
Minor
Fri 24 Jan / Fri 24
Jan
Present January Program Review
Begin prototype build
Minor
Major
Fri 31 Jan / Fri 31
Jan
Prototype build 50% complete
Major
Fri 7 Feb / Fri 28 Feb
Prototype build 100% complete
Begin testing/debugging of prototype
Major
Major
Fri 14 Feb / Fri 14 Feb Present February Program Review
Minor
Fri 21 Feb / Fri 21
Mar
Have at least 1 dimensional movement working
Major
Fri 28 Feb / Fri 28
Feb
Comprehensive Exams
Major
Fri 07 Mar / Fri 07 Mar Complete Final Report Document initial write
14 Mar-18 Mar
Minor
Spring Break
Fri 21 Mar / Fri 21 Mar Complete Final Report, first complete draft (ver. 0.9) Minor
Fri 28 Mar / Fri 28 Mar Complete Final Report, advisor-approved draft (ver.
0.95)
Minor
Fri 04 Apr
Present Final Program Review with
Demonstration
Complete Final Report, final draft (ver. 1.0)
Major
Tue 08 Apr
Present Project on Founder’s Day
Major
Thu 17 Apr
Present “Post Mortem” Review of Project
Minor
Major
18
Appendix B
Circuit Diagram
19
Appendix C
Arduino Code
20
21
22
23
24
25
26