Mechatronics: Final Lab Report

Jose Ramos
Robert Start
Travis Rogers
January 7, 2018

1
Contents
1 Introduction 3

2 Physical Platform 3
2.1 The Wolf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Enterprise and Hank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Sensors 5
3.1 Tape Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Proximity Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Track Wire Detector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.1 Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.2 Noise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4 Beacon Detector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5 Bumpers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Motors and Driving 9

4.1 Worm Drive Motors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.2 Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2 Wheels and Coupling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3 H-Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5 Launching Mechanisms 10
5.1 Fly Wheel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.2 Ping Pong Ball Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1.3 Powering the Motors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2 Dunker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6 Software 14
6.1 Tape Following . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2 AT-M6 Detection and Destruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.3 Kylo Ren Ship Detection and Destruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.4 Collision Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

7 Bill of Materials 18

8 Conclusion 19

2
1 Introduction
The final project for mechatronics this year had us design, construct, and program an autonomous robot that navigates
a field, detects and destroys three AT-M6 targets by getting a ping pong ball through their holes, and detects and destroys
the Ren Ship target by getting a ping pong ball through its much smaller and higher hole.
To build our robot, we mainly used mdf as material for our platform and housing. The software for our bot was
programmed onto the UNO32 I/O micro-controller stack, using MPLABX to write the code. Much of the hardware for our
bot was purchased at BELS, and most other parts like sensors and motors were purchased from Amazon. We also used some
sensors from the class lab kit.
The process of building this robot was an exciting, emotionally draining, but very rewarding experience. We built
the robot component by component, and integrated each component into what we already had right after building it. This
report will be divided by components of our bot, and will include prototypes, design ideas, and of course the final component
design.

2 Physical Platform
2.1 The Wolf

Our first platform design had two base layers that were modeled after a wolf head. The top layer had he two ears and
then a gap in between that the boom layer filled in to look like a nose. The top layer was only meant to hold the cannons.
All of the sensors, the drivers, and the UNO stack was designed to be on the bottom layer. The wheels were placed towards
the back of the bot and directly under our launching mechanism for better weight distribution.
This design had too many sharp edges which could have gotten stuck on the obstacles and could have been a poking
hazard in general. Our bottom base was also far too small to successfully hold all of the sensors, drivers and the UNO stack.
This design was never printed, we ended up changing to the Enterprise design before ever trying the print this design with
the laser cutter. In our later designs, we implemented more room for our hardware components by having bases that covered
more area in our 11” x 11” x 11” frame which also smoothed out our bot’s edges.

3
2.2 Enterprise and Hank

With our enterprise model we started to get more realistic in that we would actually be printing this out and finding
exact places for all of our components. On the enterprise we kept our two layers but also rounded out and extended the
edges so that the top shape had flat sides and semicircles on the front and back. Our top layer was larger than our bottom
layer because and now extended past our wheels which gave us more space. On the top layer we had the fly wheel cannon,
chimney ammo storage, proximity sensors, and our inductor for the track wire. On this model we utilized the underside of
our top layer so we could fit more of our components while still being able to lift off the top and adjust anything needed.
Our original wire layout for the enterprise ended up becoming very cluttered but we were able to hold everything that we
needed. On the underside of our top layer, we had a 3.3V power distribution board for all of our tape sensors and the track
wire perf board. On the bottom layer we had our H-bridge, UNO stack, tape sensors and our motors for the wheels. We set
our worm drive motors to face the back which gave us the idea for the Enterprise name because the robot began to look like
the Star Trek ship, the Starship Enterprise. With this model, however, our UNO stack was so far to the back the the wires
and USB extending from it went past our 11” size so we would have to reprint anyway, this would become our Hank model.

The Hank model is largely based on the Enterprise model, the main differences are that we moved the H-bridge and
UNO further towards the center of our bot so we would fit in the 11” x 11” square and we added our dunker, beacon tower,
and ammo to the top layer which became our final model for the robot. From here all of the code and hardware needed to
adapt to what the design could do because we did not want to reprint out our robot again.

4
3 Sensors
The construction of our sensors happened relatively fast, and this is mostly because of our decision to purchase some
sensors instead of building the circuits for the sensors that came with our lab kit. Our bot had a total of eight sensors: three
tape sensors, two bumpers, two proximity sensors, and a beacon detector.

3.1 Tape Sensors

For our tape sensors we choose to use the OSOYOO IR Infrared Obstacle Avoidance Sensor Module. These essentially
worked in the same way as the TCRT5000L provided to us in our lab kits. There is an IR transmitter as well an IR receiver
which would create a voltage and then compare it to the reference voltage then if it was sufficiently greater it would output
the voltage that was at the input. Due to this we were able to input 3.3V into the tape sensor and get an output of 3.3V
when there was on obstacle and 0V when there was not. With this in place we then had to calibrate the tape sensors since
they were not all the same range or sensitivity. To do this we set 4 tape sensors 4 inches away from a white MDF and then
on black tape. On the white MDF the tape sensors were set to output a 3.3V output while when on tape since the black tape
would absorb the IR signal the output would be 0V. After this we wanted to see how they would interact with the UNO. To
do this we connected the output of the sensor to the input of the UNO. When we did this however there was a slight problem.
When ever we would connect the tape sensor directly to the UNO it seemed to interfere with the tape sensor forcing it to a
3.3V output all of the time. We were not sure what the exact case of this was since it only happened to a couple but due to
this we decided to make a set of 4 buffers which the tape sensors would feed into then the output of those buffers would go
to the input of the UNO. This meant that we were now able to interfere from the UNO to the tape sensors.

3.2 Proximity Sensors

One of the hardest challenges we faced with attempting to locate ATs was to determine there was something at about
6-8inches from the outer edge of our bot. To do this we first believed that we would be able to do it with only the tape
sensor but we soon realized that we were picking up to much noise from other places. To combat this we decided to use two
proximity sensors to determine if there was a target in front of us. To do this we used the Sharp gp2y0a21yk0f. This is a
small IR sensor which has 3 terminals an input, output, ground. It would take in 5V and return a voltage proportional to
the distance away an object was. This sensor however was not able to accurately sense objects to close to it approximately
10CM. Due to this we had to place them farther back in order to get a good reading of what was in front of us. Once we
connected them to the UNO we saw that the AD value given to use was between 0-1056 and had a noise of about 70-90 when

5
idle. With an obstacle in front of them it would jump up to an AD value of approx 200. This allowed use to set a threshold
fr when the ES Framework will post an event. Now that we have both proximity sensors calibrated and mounted we were
able to continue to the detection of ATs.
Originally we were planning to use the same sensors as our tape sensors for this. The idea was to be able to align with
the target and when two proximity sensors went high at the same time we would always be at the same spot at the AT-M6
targets, from here we could stop driving and use the track wire detector to see if there was a good enough signal to indicate
that we were at an AT-M6 target that was still on. This helped to eliminate noise from the driving motors and worked
pretty accurately as long as we were following the tape closely. These tape sensors did not give us much range as proximity
sensors but they usually worked everywhere along the tape except for corners where we would curve our turns more. Close
to the final check off we were told that there would be a field with white targets and a field with brown sides. We tested
our proximity sensors on the brown side of the MDF and we had even less range. To fix this we found different, and more
powerful, proximity sensors called sharp sensors. Instead of an IO output like the tape sensors, these sensors gave us a ADC
voltage value that we could use thresholds to determine how close we were to objects. This gave us much more range and
worked out well for our method of proximity sensing. We were still able to use the same tape sensors for tape following but
now our proximity sensing became much more accurate. The only issue was that now the black obstacle set off the proximity
sensors. Sense this did not give off a track wire signal we did not shoot at the target, but just stopped at it whenever passing
it so it did not require changing anything.

3.3 Track Wire Detector

The track wire detector was one of the sensors that needed to be built from scratch. The midterm problem gave us
some insight as to how we would deal with motor noise, so we started by prototyping a basic gain and filter circuit that
would amplify the track wire signal at about 27kHz and filter out any noise at very low and higher frequencies. This circuit
initially had three gain stages of about 10 each, and then a bandpass filter with a center frequency of 27kHz. This filter was
constructed using FilterLab by Microchip (the company that makes our op-amps). This filter initially worked great, but then
we noticed that the filter would produce an output of a sine wave at the resonant frequency, even when there was no input.
This frustrated us for a while, so we decided to just not work on the filter because the official AT-M6 targets were not yet
given to us, and we didn’t want to waste any more time building a filter for a signal we did not yet have. By the time the
final targets had come out, we decided that we wouldn’t even filter the track wire signal because we planned to account for
the noise in the software by setting threshold values based on the ADC values we would get from the detector circuit.

3.3.1 Circuit
Our final circuit for the track wire detector was very simple. It had a tank circuit, three gain stages, and a peak
detector. The tank circuit used a 10mH inductor and a 3.3nF capacitor, which resulted in a resonant frequency of 27.7kHz.
The gain stages are almost identical, each having a gain of about 11, but only the first two were biased, and the last stage
was referenced to ground. This is because we wanted the full signal to be amplified for the first two stages, but by the last
stage, only the signal was gained enough that only the top half was needed. No comparator was needed because we wanted
to read the ADC value that the circuit outputted. There was no need for filters because we would either just turn the noise
sources off when reading the value, or set thresholds to account for the noise. Our schematic is shown below, and following
are pictures of the soldered circuit.

6
3.3.2 Noise
There were two sources of noise interfering with our track wire detector, the drive motors and the fly wheel motor.
To deal with the drive motors, we used side-mounted proximity sensors to detect targets that could be AT-M6s, and when
detected we stopped the drive motors and then read the track wire detector’s ADC value to determine if we were at an
AT-M6. The fly wheel motor noise was a problem when confirming AT-M6 kills because it would interfere with the track
wire reading. To account for this, we read the amount of noise that the motors were producing on the ADC reading, and
raised our thresholds that defined when the track wire turned off. We also had to add some timers and extra states for
turning on and off the motor when they caused interference.

7
3.4 Beacon Detector

For the first week working on this final robot, we spent the time to make a new beacon detector because two of ours
did not work that well and for the third the group that worked on that for the lab agreed to each try to make our own. But
this one did not end up working at all, instead of trying to figure out the one solder mistake that was causing it to not work
properly, the group that built the working beacon detector form the lab agreed to let us use it since we did try to solder up
a new one. Although it did waste some time it was only fair to both try to recreate it since both lab partners had parts in
making the working beacon detector.
For our Hank model, since we were able to use this working beacon detector, we had to figure out proper shielding
to give us a more accurate direction for the beacon for the final Kylo target. We decided to design a beacon detector tower
with a camera like slit that made sure that the beacon detector only went off when the beacon was on directly in front of the
slit. Our range extended across the field and we were able to use this to align in the first 15 seconds of starting a round and
when we wanted to eventually hit the Kylo target.

8
3.5 Bumpers
We decided to use one set of two bumper switches in order to have full coverage of any objects in front of us. We felt
as if back bumpers were not necessary since there were only very few situations where we would need them and we did not
believe these situations would ever arise. To set up the bumper we created a piece of MDF that would trigger the bumper
switch when hit. Since it was a two switch system then we will be able to differentiate between it being a left, right, or head
on collision with the object. We connected the switch to a 3.3V rail which meant that when it is triggered it will only be
able to send out a 3.3V signal to the UNO signifying a logical high for the system. With this we then now had a way to send
high and low to the UNO in response to a physical collision with an object. This allowed us to program how the bot will
react when it is hit by something.

4 Motors and Driving

4.1 Worm Drive Motors
Most of the money spent on our bot went to the worm drive motors. The initial reason we purchased the motors was
because of the high torque: we wanted to be safe with how much torque we would need in case our bot got too heavy. With
the worm gear motors, we never had to worry about the motors not having enough torque. However, they did cost us a
whopping 30 dollars each.

4.1.1 Advantages
What worked well for us with these motor was the way the worm gear worked. If no current was being supplied, then
the gears would lock and the output axis would be fixed. This was great for precise positioning of our bot when detecting
AT-M6 targets and lining up with the whole, as well as for when detecting the beacon. We had our bot tank turn and stop
when it detected the beacon, and the motors stopped very precisely so that we were lined up with the hole on the ren ship.
The worm drive motors definitely came in clutch for us.

4.1.2 Disadvantages
The worm drive motors also caused some problems for us. First off they were pretty heavy, and since we mounted
them in the back of our bot they added to it’s already rear-heavy weight. Since the gears locked very suddenly when the
current stops being supplied, the entire bot would jerk when we stop or change direction. The heaviness of the bot didn’t
help here either. Often the front end of the bot would raise up off the ground, and this cause the front tape sensor to have
false readings, which affected the way we followed the tape and would often cause us to drive out of bounds. To deal with
this, we had to lower our driving speeds, and often recalibrate the front tape sensor.

9
4.2 Wheels and Coupling
We bought Razor scooter wheels for our bot, intended for use with a bearing. Since we were driving with motors,
we didn’t need a bearing, we just needed a way to couple the motor shaft to the wheel. Online options were available that
would be specific for our need, however they were too expensive, so we went to hardware stores. We tried four different
hardware stores, looking for something to couple a 8mm shaft to a 22mm diameter, and couldn’t find anything. No one in
any store could help us or think of any way to do it, and we even spent some money on a very ridiculous yet hopeful idea with
plastic tubing and metal fasteners, but all failed. We ended up just laser cutting out a shape on acrylic sheets, and glued
them together to get a pretty good piece for coupling. This method was very simple and seemed to be the popular method
amongst the other teams, so we were a little disappointed with how much time we spent trying to couple them through other
methods.

4.3 H-Bridge
To control the speed and direction of our motors, we used the DRV8814 Dual H-Bridge Module. The module uses
two high current drivers that consist of power MOSFETs to drive the motors. The module took four inputs, one enable and
one direction signal for each motor. The enable signal was a PWM signal that we generated using the PWM library. The
direction signal was just a ON/OFF signal we generated with the I/O-Ports library.

5 Launching Mechanisms
5.1 Fly Wheel

10
5.1.1 Design

Our original Wolf design had two cannons made of PVC, one facing the right for the AT-M6 targets and one facing
straight forward for the final Kylo Ren beacon target. These cannons would rest within an MDF tower on our top base that
would be able to support the PVC cannon, motors and servos. Each of these had their own fly wheel mechanisms, servos,
and ammo storage so they could be completely independent of each other. The lower cannon was 7” above the ground, just
high enough to shoot through the AT-M6 targets, and faced straight out with no angle shot. The second cannon was up
at the highest point within our limit and was angled at 45 degrees from the horizontal plane. This was meant to give us
our best shot for hitting the Kylo target. Both of these cannons also had each their own ammo storage shoots also made of
PVC. Since the AT-M6 cannon was lower to the ground, we would have fortunately been able to store more ammo with no
clue how accurate our shooter would actually be. The taller Kylo shooter was intended to hold 3 shots to try and take out
the target. Both shooters had their own servos that would be used to restrict the flow of ping pong balls so that we could
control shooting one at a time. The idea for this servo would be to hold all of the balls back until the cannon was ready to
shoot and then the servo would receive a separate pulse that would then allow balls to pass through. We would have to time
this and use the servo to stop the flow just long enough to send one ball through without jamming.

After moving to the Enterprise design, we tried to change the design so that we would only use one MDF cannon
for both targets. This one cannon rested on the top base slightly lower to the ground than with the Wolf model but we
realized that the tower would not have been stable enough to support the cannons. Using two cannons would have been too
heavy, require too much current from the battery, and have been too large to with our PVC cannon designs. Using the PVC
would have been nice since the circular barrel for the ball to travel through would have guaranteed more accurate shooting.
However, the PVC would have been too heavy for our robot and cutting into the PVC would have been too difficult. Making
the cannon out of MDF gave us more control of the size of the cannon and we could also cut easily into MDF with the laser
cutter. The ability to customize our cannon more and mount it easier onto the base caused us to switch to an MDF cannon.
For our enterprise model, we decided to use only one cannon out of MDF since it was lighter and easier for us to use
that PVC. This one cannon rested on our top base and pointed to the side. As we passed with our proximity sensors and
if our track wire sensor went off then we could assume that our robot was facing the AT-M6 target directly. For ammo, we
designed a chimney like attachment to the cannon with a servo that would control the flow of ammo. Instead of using pulses,
we modified this servo to be a slow moving motor with a circular wheel with a cut out the size of one ping pong ball. Since
MDF is smooth after being cut with the laser, the servo never jammed with ping pong balls and would only let one through
every rotation. This made it easy to make sure that one one ball would ever be shot at one time. The problem that arose
was that our base was too low to just shoot the balls directly out of the cannon, this gave us more room for ammo, but we

11
needed to shoot higher to successfully hit the targets. To fix this we added curved ramps so that we could add hight to our
shots. The idea from here was to be able to hit the AT-M6 or the Kylo target with the ramps attached and varying the
PWM signal to the fly wheel motor. After a couple of days experimenting with different ramp angles and PWMs we could
never reliably hit the Kylo target. Instead we decided to use a shorter and slightly curved ramp to guarantee hitting the
AT-M6 targets and then devise a separate method to get the Kylo target.
Originally, in out Wolf model, we searched for some type of flexible pipe that could hold ping pong balls that we would
wrap around our cannon tower for ammo. After searching all over Santa Cruz stores, we were unable to find any type of pipe
that achieved all of our demands. This helped influence our decision to abandon the two cannon tower and move to just one
cannon for the Enterprise model.

5.1.2 Ping Pong Ball Storage

We were also able to make ammo storage easier with MDF. On the Wolf bot model, we could never find a way to hold
enough ammo with the large and bulky PVC pipes without going past our height requirements. After creating the MDF
cannon and chimney for the enterprise model, we could still only hold 2 balls at most but this was a much more reliable
launching mechanism. Since we have the ability to customize and cut easily with the MDF we could create a ramp system
that extended around our Hank robot which allowed us to carry more ammo easier and we were able to easily attach it to
the base. With this ramp system, we could hold 8 ping pong balls which we never really needed but we wanted to hold that
much just in case.

5.1.3 Powering the Motors

Initially when testing the fly wheel motors, we were just supplying a constant DC voltage across it. This showed us
the power of the motors, but the distance of the launch was not consistent. We weren’t sure of the best way to drive these
motors, and we were planning on using the supplied DS3658 Driver Module. One night when we had not yet gotten to
constructing the cannon, the savior Professor Gabriel Elkaim came to the lab with pizza and answers. He recognized our
beefy motors and showed us how to use the TIP122 Darlington transistors to drive them so we can control the speed of the
motors using a pulse-width modulation (PWM) signal. This made the distance much more consistent, and all we would need
in terms of hardware is a little bit of space on a perfboard for a small circuit. Our schematic is shown below.

12
5.2 Dunker

Changing to the Enterprise model gave us a reliable cannon for the AT-M6 and switching to the Hank model gave
us more than enough ammo storage. However, we still had the problem of dealing with the Kylo target. Immediately after
switching the the Hank model we had no idea how we would get the Kylo target and we built our bot accordingly. After
being able to reliably shoot AT-M6 targets and successfully count how many with our state machine we shifted our attention
to the Kylo target. Seeing this successfully done with other groups, we decided to use a dunker to reliably get the Kylo
target.
The dunker is a servo that has a rod on it that holds a ping pong ball that, when we get to the Kylo target, will turn
and dunk the ball into the target. Since the Kylo target is higher than our robot could reach initially, this method gave us
this extra height since the servo started down. With other teams, however, we noticed that they were often having trouble
keeping hold of the one ping pong ball designed for this final target. Since we had worm drive motors, our bot jerked around
even more when changing directions which meant that we had to find a more secure way to hold the Kylo ammo. Instead of
a circular end to hold the ball, we decided to implement a square ping pong ball holder at the end of our dunker that would
tightly grip the ball. To get it out of that only when we want, we added another servo at this holder that would supply
enough force to push the ball through. This worked really well for us and the ammo would not fall our unless the servo
pushed it out and the ammo was not stuck enough to jam the servo. With this we were able to successfully run through the
track and get every target.

13
6 Software
6.1 Tape Following

Tape following was the first part of the state machine that we tried to implement and also ended up being the most
complicated. On our robot we had three tape sensors, one in the front center and then two to the left. Our idea was to follow
the tape clockwise by using the two left tape sensors to align with the tape. The front tape sensor was supposed to only go
off when we reach on of the center tapes, a corner, or start on the tape when we start completely off tape.
We initially assumed that we would start off of any tape, this is our NoTape state and our idea was to drive lazily to
the left until we got to some tape. Whenever we entered this state we started an Oh Crud timer so that we wont get stuck.
If this timer expires, then the robot will reverse a little in the Reverse sate and start again in the NoTape state. From this
NoTape state, if only the right tape sensor gets on tape, then we enter the FixRight state. If the front tape sensor and either
the left or right sensors do not detect tape the the robot will also reverse like after the timeout. If the left and right tape
sensor detect tape then the robot goes into the follow state. In the reverse state, the robot reverses left for a certain time.
When the timer expires, the state machine always goes back to NoTape so that the sensors can take in new events.
In the follow state, both motors move the wheels at the same speed. If the left tape sensor goes off of the tape, then
the robot goes into the FixLeft state. If the front tape sensor detects tape then we assume hat we have hit a corner and do a
timed tank turn for the corner in the Turnright state. If the right tape sensor looses tape then the robot adjusts to the right
in the FixRight state. Finally, the FixRight and FixLeft state stops the respecting wheel for a sharp turn to adjust. This is
so the robot can adjust if it drifts off of the tape.

14
6.2 AT-M6 Detection and Destruction

To effectively locate and destroy ATs we implemented a two way check and also a conformation check. The way this
would work is if we were in the tap following state and both of the proximities go off then we will know that we are in front of
well either an AT or obstacle. We would then go into a check state which would reads the AD value of the track wire sensor
and if this value was above our threshold then we would know that it would have to be an active AT. If these conditions are
passed then it will go though the rest of the shooting stage which spins the rc servo and motor to shoot one ping pong ball
at the AT. After the shot is completed then another checking stage will be initiated which continuously checks to see if the
AD value read from the track wire sensor is below our threshold. If it did indeed drop below the threshold then we have
a confirmed kill and the overall kill count gets incremented by 1. If the track wire is still on then we will go into the state
again and fire another shot until it is hit. With this we were able to successfully hit and confirm that we destroyed an AT.
Once our counter hit 3 we would then go into our next state machine which is the kylo sub state machine.

15
6.3 Kylo Ren Ship Detection and Destruction

Once our count reached 3 we will then know that we have successfully destroyed all of the ATs and thus now enter our
final sub state machine which is the Kylo sub. When the final AT has been destroyed we will stay in the tape following state
and continue to be there until either of the bumpers are hit. This would indicate to us that we were either at kylo or at the
obstacle. We then directed the bot to do a series of turns that would allow it to be right in front of kylo or to be clear of the
obstacle. The bot would always first back up, tank turn to the right, move forward, tank turn to the right, move forward,
and then it spins. As it spins it will be looking for a beacon event which would then give us the location of the kylo hole.
The bot would then march forward for 1sec and if it is bumped during this time the dunker should be aligned with the kylo
hole which it would then push the ball into the hole. If we in turn hit the obstacle instead of kylo the bump would not be
triggered and instead would again spin until it gets another beacon event which would then cause it to again go forward for
1sec and search for the bump event. It would continue this behavior until it reached kylo and inserted the ball into the hole.
All in all this system worked great mainly due to the fact that we had a great mechanical shield on our beacon detector and
allowed use to get precision when lining up with the hole for kylo. After this we will be finished with the course.

16
6.4 Collision Detection

Collision detection probably ended up being the most difficult part of the state machine to implement. We had to
find a good enough way to properly distinguish between the obstacle and the Kylo target since we could bump into either at
any given time. To do this we started by addressing one bump, we assumed that this would be the Kylo target since it did
not extend into the field. Our idea is that if we bumped twice frequently then we assumed it would be the target. For just
one bump, we assumed it was Kylo and went into the QuickReverse state and then the curve state which was a programed
curve that should have gotten Hank across the target and then go back into the TapeState to continue tape following. If we
bumped again during this part then we would assume that the robot hit an obstacle and we had programmed movement to
effectively move around the obstacle and then continue tape following.
All of this was predicated on our AT count being less than 3, meaning that we had not gotten all 3 AT-M6 targets
yet. If he robot had already gotten all of the AT-M6 targets then one bump would instead take us to the FindKylo state and
do that programmed movement. If it bumped again then we would go back to our obstacle programmed movement.

17
7 Bill of Materials

ITEM SOURCE QUANTITY COST/UNIT TOTAL

uxcell DC Worm Gear Motor Amazon 2 30.09 60.18
Razor Scooter Wheel Amazon 2 7.5 15
Riorand ES08MA Servo Amazon 3 5.95 17.85
Cylewet V-156-1C25 Switch Amazon 2 1.49 2.98
OSOYOO IR Obstacle Sensor Amazon 3 0.99 1.98
Sharp IR Analog Distance Sensor Amazon 2 3.25 6.5
Ball Caster Amazon 1 5.99 5.99
DC Motor Set Ebay 1 8.9 8.9
MDF Sheet 20x20 BELS 3 3.5 10.5
Assorted Nuts and Bolts BELS/Hardware Stores 3.75
Assorted Hardware Components BELS 12.62
Total Robot Cost: 146.25

18
8 Conclusion
Below is a link to our finished Hank the Tank the Turkey completing the course:
https://youtu.be/iL8Negu6Ulc

Overall, all three of us were very satisfied with how we completed the project. We moved very swiftly toward the
beginning of the project, because we took action very fast before completely planning things out. We designed a platform on
SolidWorks pretty quickly and got a driving robot built that can be programmed to follow tape. I think part of the reason for
our quick progress was because of the way we approached each task or component. We designed and programmed together,
instead of splitting the tasks up to be done by each person. This way, we all knew how each part of our bot worked so that
integration would be easy for all of us.
For the first couple weeks, we were ahead of most groups, as we were the one of the first groups to successfully tape
follow and shoot down AT-M6s. However, once we got to destroying the Kylo Ren Ship target, we had many setbacks that
delayed further progress. since we originally planned to use the fly wheel to take out Ren, we didn’t have any designs for
the dunker until we realized the fly wheel was very close to impossible for Ren. So designing the dunker took some time.
Another major setback we had was within our state machine, we didn’t initialize the variable we used to keep track of the
current event in each state machine. Our state machine started to crash when it got events and we thought we were doomed
and had to re-write our entire state machine. This had us stuck for about a day until a friend with the same problem showed
us the light and told us to initialize the variable. Other setbacks included hardware issues like loose connections, or parts of
our bot coming apart, but no setbacks were big enough to stop Hank.
We were the 7th group to checkoff, and we were very proud to be done. We didn’t touch the bot until the competition,
when we added black paper skirts to the bottom of our bot to block out the media theater lights. Hank advanced through
three competition rounds, all well fought. Currently, Hank is no more as his body was torn apart and his organs were returned
to the fab lab. Hank is now one with the force. May the force be with you.

19