5. 4
Executive Summary
Team Watergate was challenged to compete with other firms in constructing a small,
inexpensive Over Sand Vehicle (OSV) that was to autonomously survey a remote island in the
Pacific Ocean. The team’s three missions included: navigating the island’s sandy terrain to
within 250 millimeters of a specified pool of water, measuring the temperature of the water to
within three degrees Celsius of the actual temperature, and transmitting the temperature back to
the mission control. Additionally, Watergate planned to determine the depth of the water to
within four millimeters and transmit the results back to the mission control.
The team’s OSV was randomly placed and oriented in an area within one meter from the
left side of the four meter by two meter sand box representing the island. The vehicle used a
four-wheel drive train with differential steering and a gear motor attached to each wheel to orient
itself by communicating with the overhead vision system through a Radio Frequency transceiver
(RF). To measure the temperature and depth of the water, the team created an arm that was
attached to its own motor with a gear and rack to move sensors into the water pool when that
motor was enabled and the wheel motors were disabled. The arm was designed to complete the
mission by using a digital temperature sensor, a water detection sensor, and a push button.
The vehicle was designed to follow a control algorithm through Arduino coding that
communicated with the overhead system through the RF transceiver. After orienting itself to face
south, the vehicle was designed to approach the southern boundary, rotate counterclockwise to
face East, continue straight until just before the vehicle comes inline with the pool of water,
rotate counterclockwise to face north, and continue straight until it approaches the northern
boundary. The vehicle was designed to then rotate clockwise to face the pool of water and
approach the pool to get within range for the arm. The arm was designed to then submerge into
the water so the sensors could read the temperature and depth of the water.
In order to test their designs, the teams participated in a competition day on May 6, 2015.
While Watergate’s OSV seemed promising, the vehicle did not work as planned. Prior to the
competition two of the team’s motors broke and the new shipment did not arrive in time. Though
the team was worried about being able to navigate the sand, in the first trial, the motor for the
vehicle’s arm malfunctioned which prevented the vehicle from moving at all. In the second trial,
Watergate’s OSV oriented south, traveled to the southern boundary and rotated counterclockwise
correctly; however, shortly after, the OSV got stuck in the sand due to two non working motors.
6. 5
Introduction
Watergate, our team from a water-based engineering firm, was challenged in January
2015 to create an autonomous Over Sand Vehicle (OSV) that could complete various water
missions on a remote island in the Pacific Ocean. We were instructed to create a vehicle that was
able to autonomously propel itself over the island’s sandy terrain, navigating around obstacles to
approach a specified pool of water. We were additionally tasked with designing the vehicle so
that it could measure the temperature of the water in the pool to within 3 degrees Celsius of the
actual temperature and to transmit the temperature of the water back to mission control. In
addition to our main tasks, we were also given two bonus missions that include: measuring and
transmitting the salinity of the water back to mission control to determine if the water was
freshwater or sea water and measuring and transmitting the depth of the water back to mission
control to within 4 mm. We chose to focus on accomplishing our primary tasks and the water
depth bonus mission.
To guide the vehicle’s design and development, we were given several product
specifications and constraints. The OSV was limited to an overhead footprint of no more than
350 mm x 350 mm and could weigh no more than 3 kg. To satisfy the size and mass restrictions
for our vehicle, we made our OSV overhead footprint 340 mm x 330 mm and the total mass 1.97
kg, well under the constraints. Additionally, the use of prebuilt systems was limited to parts with
no more than 3 components. Regarding power, the OSV was prohibited from utilizing both
lithium based batteries and internal combustion engines, and the vehicle had to be capable of
running all systems at full power for at least 10 minutes. We used a 12 V 2000 mAh battery to
power the micro gear motor attached to each wheel and used a 9 V 300 mAh battery to power the
Arduino, both which allowed the vehicle to run at full power continuously for 10 minutes.
As our team learned how to make the OSV move and complete the tasks autonomously,
we made sure to meet the requirements regarding the vehicle’s communication. We were given a
100 mm x 100 mm tracking marker to place on top of our vehicle, so the Radio Frequency (RF)
transceiver could communicate with the overhead system to track and transmit the vehicle’s
location back to mission control. Since the tracking marker needed to lie flat on the top of the
vehicle, we created wood stands where the marker was placed each time we tested. All teams in
the competition were required to use an Arduino compatible microcontroller, to have all of their
7. 6
batteries operated by a switch, and to spend no more than $350. Our team had to work together
to make sure that we were not violating any of the rules as we designed and built our OSV. Due
to time and financial constraints, we decided to focus on the primary missions and the depth
mission.
The island’s terrain was important in understanding the way we designed and coded our
OSV. The island was 4000 mm x 2000 mm and consisted of loose and rutted sand that had an
average depth of 15-60 mm above the rocky substrate. Several obstacles were located on the
island that our vehicle needed to dodge in order to navigate to the pool. The coordinates of the
obstacles were given to us when we were tasked with the mission, so our team brainstormed to
find the best method to avoid these obstacles in our navigation. Enough travel room existed
between the obstacles and the edges of the sand, so we designed the control algorithm to have the
vehicle maneuver along the edges of the sandbox until it became closer to the vehicle. Once the
OSV reached the pool, it was designed to determine the temperature of the water, which was
within -20 to 50 degrees Celsius. Our team planned to complete the primary missions and to also
determine the depth of the water, however, we chose not to attempt the second bonus objective
of determining the salinity of the water due to time and financial constraints.
The base of our design relied on a 200 mm x 250 mm x 10 mm pinewood chassis, and we
created a 3D printed arm that moved into the water using a rack and pinion system, which was
attached to a Servo Motor. This arm was attached and hung over the front of the OSV and was
used to allow the sensors to reach inside of the pool and test the water. We thought that 3D
printing the arm would be beneficial to us because we printed it using PLA plastic, which was
water resistant unlike other options that we had such as wood. Additionally, we could reprint the
arm if something needed to be changed quickly and reliably. The arm held several sensors
including a push button, water sensor and temperature sensor, all of which were necessary
components for completing both the base and bonus missions. The arm’s sensors and Servo
Motor were powered by the Arduino, which was powered by the 9 V battery. The four off-road
wheels were attached to DC micro gear motors that enabled the vehicle to move with power from
a 12 V battery. We chose these Sparkfun wheels because they were made of soft black rubber,
which had sufficient research/evidence of providing great traction on the sandy terrain.
8. 7
We used off-road Sparkfun wheels with a diameter of 120 mm and a width of 60 mm to
reach an appropriate height above the ground. The wheels attached to the motors were held in 3D
printed motor housings made out of PLA plastic that were designed specifically to hold the
micro geared motors. The motor housings were hot glued to the bottom of the chassis so that
sand that was kicked up would not ruin the fragile gearboxes. We created a four-wheel drive
differential steering system using a H-bridge for our OSV, which allowed for easy maneuvering.
This differential steering allowed us to effectively turn on a point by telling the wheels on one
side to move forward and the other side to move backward through our coding. This ability came
very useful for navigating the island, as having such a small turn radius opened up many
different navigation options.
With the multiple motors and sensors for our vehicle, an intricate circuit design was
needed to get the vehicle working. We created sub-teams within our overall team, Watergate, to
specialize with different aspects of the vehicle, one of them being circuitry. The team member
that worked on most of the circuitry was also apart of the programming sub-team, so there was
someone with an understanding of all the electrical and programming components. While our
team lacked prior programming experience, the sub-team members specialized in that aspect of
the project worked very hard to program the vehicle. Our team knew that having the OVS
moving autonomously required programming; and in order to have any success, we needed to
learn how to code the Arduino very well.
Over the course of the semester, our team learned that hard work is essential for success.
Our programming sub-team was determined to having the OSV working and they attended
evening learning sessions for help. This proved that hard work could result in a desired outcome.
While our team, Watergate, initially wanted to determine the depth of the water in the pool and
had the components to do so, with our lack of initial coding knowledge, our coding sub-team
needed to focus on coding the primary tasks. During competition day, although our vehicle was
not completely successful, our vehicle’s coding worked very well. We believe, that in
comparison to our direct competition, our program worked the best, even though the vehicle was
not able to complete the missions. One of the challenges for our team was selecting the best
motor for the OSV. We had decided upon the DC micro gear motor with a 289:1 gear ratio based
on our predicted weight of 1.79 kg, while our finished OSV was 1.97 kg. This difference in mass
9. 8
did not impact the vehicle enough to cause problems; however, we sustained heavy damage to
two of our motors approximately a week before the competition that rendered them to be only
capable of providing half of the possible power to the wheels. We ordered motors to be delivered
the day before the testing event; however, the shipment was sent to the incorrect location, and on
testing day we were left without four fully working motors. During our first run, the Servo Motor
malfunctioned, digging the arm into the sand and preventing the rest of the vehicle from moving.
Between our first and second run, our team came together to brainstorm out how we can still get
the vehicle to move with broken motors. We decided to each call some people that we knew who
may have used the same motors as us, and we luckily had a friend that was no longer using four
similar motors to what we needed but with a gear ratio of 1:210. With 22 minutes until our
second run, a team member ran to grab the motors. The team was only able to add one of the new
motors before our final run due to time constraints.
We were hoping that having a working motor with a different gear ratio than the other
gears would be better than having a broken motor, so we began our final run. We were surprised
to find that the OSV worked relatively well orienting itself and beginning to travel to the pool of
water with one motor that had a different gear ratio than the rest and one still only providing half
the power. The vehicle traveled to the southern boundary, rotated to face east and continued a
short distance until getting stuck in the sand. However, during prior testing, we were able to
exhibit and prove that our vehicle was indeed capable of navigating us to the pool, determining
the temperature of the water, and transmitting that temperature back to mission control. While
we were unable to perform optimally on testing day, we believed that there were a lot of great
takeaways from the issues that arose. We believed that our final product and design was an
optimal option for the primary missions for the competition.
Preliminary DesignShortcomings
As our team began the construction of the vehicle, we began discovering many
unanticipated shortcomings in our preliminary design. When we began testing the navigation of
our vehicle, we realized that we did not create an area to put the marker so that the vehicle could
communicate with the overhead vision system. We had not previously taken into consideration
that the RF communication marker would take up about 1/9 of our total OSV’s surface area. To
resolve this minor problem, we cut two pieces of wood to add to the sides of the chassis to
10. 9
increase the height of our wall. We also cut another piece of wood to lie across the two new
raised pieces, creating a bridge where the marker was placed before testing. This was an easy and
efficient system, because when we were not testing, we still had easy access into the components
of our OSV that rested on the chassis by just lifting the marker and piece of wood. Another
shortcoming that we had to account for was the expansion of the PLA plastic when 3D printing.
Both the arm and motor housings had to be printed at least one additional time so that
modifications could be made in the dimensioning to account for the expansion. After printing the
rack and gear for the arm, the pieces did not fit together as nicely as we wanted, so we made
adjustments to prevent slipping. We also adjusted the sizing of the motor housings to make sure
that they were the perfect fit.
Our team also experienced shortcomings related to the electrical circuitry for the vehicle.
There were many instances, especially as the circuitry became more complicated, when the wires
connecting different parts of the breadboard would come out of the breadboard. Since our team
was divided into sub-teams, not all team members knew about the circuitry of the vehicle in
detail. So, when the circuitry specialist was not at open lab hours, whenever a wire on the
breadboard came out, we had to contact that team member who knew the circuitry in detail to fix
the problem. Unlike the previous shortcomings that had an easy solution, this problem was more
of a challenge to overcome. We considered using a perfboard, but decided to focus our efforts on
fixing the other problems that we had encountered. To help this problem, we had tried to have
shorter wires go through the longer wires when getting to their spots on the breadboard.
Lastly, the poor quality of our motors was something no member in our group
anticipated. While our group was researching potential motors in the preliminary design stage,
we had only focused on finding a motor that would meet our propulsion requirements that we
had calculated using Newtonian physics. Fortunately, we found a motor that met our criteria.
However, the motors were expensive and tended to break easily. We had to buy several extra
motors throughout our building and testing stages. This made testing our mission code very
difficult, because we had to determine if our failures were due to the motors or the code itself.
Unfortunately, two motors had broken the week before competition and the motors we had
ordered the week before the competition were shipped to the wrong location. In an attempt to
solve this dilemma, we decided to borrow similar motors from one of our team member’s
friends. Although it seemed impossible to solder brand new motors onto our vehicle the day of
11. 10
the competition, we accepted the challenge. However, we only had enough time to solder one
new motor onto our OSV before it was our time to complete the mission. This one motor was
noticeably more powerful than the others, which helped the lack of power from the other broken
motor but caused the vehicle to not complete work properly. While we did not resolve the motor
issue prior to the day of the mission, looking back, our group realized we probably should had
tested our coding primarily with the tanks rather than the vehicle to prevent overuse on the
motors.
Even with all the trouble our group faced after the preliminary design phase for the OSV,
our group was pleased with the way we faced these challenges. In the end, we were glad that our
team had the time to adjust our design that pure math and physics could not account for, and
luckily, all of our members in the group learned many important lessons from these preliminary
design shortcomings.
Final Design Details
Figure 1
Structure
We made the Chassis for the OSV out of pine plywood bought from Home Depot with
dimensions of 250 mm x 200 mm as seen in Figure 3, and we created sidewalls by gluing smaller
pine plywood pieces to the edges so electrical material on the chassis could not fall off when at
an angle or when navigating through the sand. We also added larger plywood pieces to either
side to create a stand for the maker to sit on so that it could be seen by the overhead vision
system. Four motor houses were attached to the bottom of the chassis to hold the motors. These
12. 11
motor housings, as seen in Figure 4 were 3D printed and had an open area in the back to allow us
to wire the motors. The motor housings were carefully created so that they were tight enough
that the motors could not easily fall out. The wheels were attached straight to the motors with a
small metal axle that came with each wheel, and we used the pin that came with each wheel to
hold the flat edge of the axle still so when the motor was powered, the wheels rotated.
We 3D printed a rack and pinion geared system as seen in Figure 2, to maneuver the arm
with the sensors into the pool. We 3D printed the arm out of PLA plastic and be seen in Figure 13.
This arm was attached and hung over the north side of the OSV and was used to allow the
sensors to reach inside of the pool and test the water. The arm held several sensors including a
push, water and temperature sensor, all of which were necessary components for completing
both the base and bonus missions. The arm was attached to the chassis by the arm holder which
was 3D printed out of the same material as the arm and can be seen in Figure 9. We also 3D
printed the gears that allowed for the arm to be moved up and down and into the water. The gear
can be seen in Figure 15.
Figure 2
Figure 3
13. 12
Figure 4
Propulsion
Overview: In order to allow for our OSV to reach from our drop off point to our
destination we had to make sure that it would be able to propel itself over the sand. To account
for this we first had to find a motor that could rotate our wheels at a speed that we felt would be
appropriate for completing our mission, all while making sure that the motor provided enough
torque to make the wheel overcome the rolling resistance created by the sandy terrain. Finally
once this was accomplish we had to make sure that the motor would not provide too much
torque, which would cause our wheels to slip. In order to pick the right motor for our vehicle we
started with what we knew and what we had already decided on.
Our knowns:
We decided to purchase Off-Road Wheels that have a radius r=6cm, along with a width
of 3cm.
We initially aimed for a speed of around 32rpm.
We aimed for a mass of approximately 1.7kg however it ended up being 1.97kg.
The coefficient of rolling resistance we assumed to be 0.3.
Our vehicle will have four wheels, and will be powered under 4 wheel drive, meaning
that each wheel will have its own motor.
We are assuming that our vehicle will be traveling in equilibrium and that its weight is
distributed evenly over all four wheels.
Our first step in choosing a motor is finding the required torque to allow the wheels to overcome
rolling resistance.
15. 14
We then had to check to make sure that the wheel would not slip on the terrain with the required
tractive effort we had calculated.
𝜏 𝑤
𝜏 𝑤
< 𝜇𝐿 𝑤
0.087𝑁 ∗ 𝑚
0.06𝑚
< (0.7)(
1.7𝑘𝑔 ∗ 9.81
4
)
1.45𝑁 < 2.92𝑁
Therefore it does not slip.
Figure 6
Once we calculated this we tested different motors using a motor characteristics curve as seen in
Figure 6 and chose the appropriate Micro Gear motor as seen in Figure 7.
Motor Characteristic
16. 15
Figure 7
Motor Characteristics:
Gear ratio: 289:1
Stall torque: 40 oz-in
No load speed: 45 rpm
This is based on the motor receiving a voltage of 6V.
We found the operating point using a slope equation.
𝑌 = 𝑚𝑥 + 𝑏
𝑇 = 𝑚𝜔 + 𝑏
𝑚 =
0 − 40
45 − 0
𝑁 ∗ 𝑚
𝑟𝑝𝑚
𝑏 = .4𝑁 ∗ 𝑚
𝜏 = (
−40
45
) 𝜔 + 40
𝑊𝑖𝑡ℎ 𝑡ℎ𝑒 𝑟𝑒𝑞𝑢𝑖𝑟𝑒𝑑 𝑡𝑜𝑟𝑞𝑢𝑒 𝑜𝑓 𝜏 = 12.32 𝑜𝑧− 𝑖𝑛, 𝑜𝑢𝑟 𝑠𝑝𝑒𝑒𝑑 𝑤𝑖𝑙𝑙 𝑤𝑎𝑠 𝜔 = 31.1 𝑟𝑝𝑚
This rpm was almost exactly in line with our target speed of 31.8 rpms’ for the OSV. We
felt that the precision of our target speed to the speed we will be getting from the motor helped
us perform the mission objectives. For the actual test we unfortunately had 2 motors that
malfunctioned prior to the contest. This forced us to attempt the mission at less than full capacity
DC Gear Motor
Micro Gear motor - 90 RPM(6-12V)
ROB-12285 ROHS
https://www.sparkfun.com/products/1
2285
17. 16
and was the reason we were unable to complete the mission. However once we were able to
install 4 working motors after the contest our OSV was capable of traversing the sandy terrain.
OSV Mission
The batteries that had exposed leads for recharging were required to be equipped with
connectors at all times.
Team Watergate was one of many engineering firms competing to build a small fleet of
Over Sand Vehicles that will be deployed to a remote island in the Pacific Ocean. Our Over Sand
Vehicle was tasked to navigate over the sandy terrain of the island, analyze a certain element of
the island, and transmit the data we received about our natural resource back to our firm.
Along with our mission, each firm was given the same product specifications. Our OSV
could not exceed a mass of 3 kg and had to have an overhead footprint size less than 350 x 350
mm. Also, using any pre-built systems with three or more associated components was prohibited
along with the use of lithium based batteries and the use of internal combustion engines.
Furthermore, our OSV had to run all systems at full power for at least 10 minutes without
replenishing or recharging its batteries. For performance requirements, the first one stated that
our vehicle had to be placed on a 30 degree incline without slipping or tipping. The next
requirement said that our OSV had to complete all of our base missions within a five minute
timespan. In terms of communication requirements, during our mission our OSV needed a 100 x
100 mm tracking marker placed on top. Our vehicle also had to transmit and receive RF
communications using the APC220 Radio Communication Module.
For our control and navigation requirements, we had to use an Arduino compatible
microcontroller to make our OSV autonomously navigate to a specified point within 250 mm. To
keep our vehicle safe, our OSV could not use any liquid-in-glass thermometers. To continue, our
OSV could not have any dangerously sharp objects (exposed nails, pins or razor blades), and all
of our batteries had to be controlled by a switch. In terms of cost, our OSV’s total as-built
replacement cost had to be less than $350. To show our total cost, we had to include a final bill
of materials with fair market value for each component, including anything we 3D printed.
18. 17
The remote island has very sandy terrain throughout with an average depth of 15-60 mm
above the rock substrate. There are multiple different spots throughout the island consisting of
things such as air vents, water pools, deposits of metal and boulders. Furthermore, our team of 8
engineers was given the task of analyzing the water pools throughout the island, while the other
necessary tasks were distributed amongst the other engineering firms. The Water Sampling
challenge included navigating to the edge of the water pool, measuring and transmitting the
temperature of the water in the pool, and transmitting it within 3 degrees Celsius back to the
command center. On top of those missions, our team also planned to measure the depth of the
water within 4m and transmit the data back. To perform these tasks, our team decided to use an
arm that would lower into the water. Attached to the arm was a temperature sensor and a water
sensor, and inside the arm was a push button that protruded out slightly from the bottom. The
temperature sensor simply measured the water temperature and transmit the data back to us. The
water sensor would detect when the arm first came into contact with water and start a timer. This
timer would end when the button was pushed from the bottom of the pool. With the time it took
to reach the bottom, and knowing the speed our arm moved down, we could have calculated the
depth.
Our OSV was parachuted down to the island in a random location with a random
orientation; it began communicating back to the command center immediately in order to track
its location as it traveled through the island.
By using RF communication, our OSV was able to successfully communicate its location
to our firm as it rotated towards its first goal of facing the south side of the island. After facing
the south side, our vehicle was able to successfully navigate to the south side of the island and
turn towards the east side of the island. After the front faced east, as it moved forward it began to
move off track at an angle due to a propulsion issue with the axles. Eventually it hit the south
side of the island and got stuck. Because it got stuck, it never did reach its ultimate goal of the
water pool. Because of this, we were unable to perform any of our required missions on
competition day.
19. 18
Power
To provide power to our motors we used a Tenergy 12V 2000 mAh NiMH Battery Pack
w/ Bare Leads. This battery pack provided power to our four motors, each powering one wheel.
Two H-bridges were contained within a Texas Instruments L283d chip that enabled the Over
Sand Vehicle to navigate the terrain. We were able to make changes in the direction of the
current flowing through the motors. The battery packs have a total current draw of 1440 mA and
can run for 84 minutes while powering the motors. To provide power to our Arduino, we used an
AccuPower 9 volt, 300 mAh NiMH rechargeable battery. The sensors and Servo Motor draw
power from the Arduino at 5 V. The current draw for this battery is 221.5 mA and can power the
Arduino and its components for 81 minutes when powering the Arduino and its components. We
chose to use NiMH batteries for their capacity, durability, and energy density, which allowed our
OSV to run for an ample period of time. We also purchased a Tenergy Smart Universal Charger
for NiMH/NiCD Battery Packs: 6v - 12v to allow us to rapidly charge our batteries. This was so
that we could run the batteries for many hours more than the competition called for during
testing.
Sensors
The Over Sand Vehicle used four different sensors to receive and transmit the necessary
data to complete the Water mission, all of which were compatible with the Arduino
microcontroller.
A distance sensor was used to ensure that the OSV was in close proximity to the pool of
water. The distance sensor interacted with the Arduino with three wires: power, data, and
ground. The power supply wire was used to receive the five volts of power that the Arduino
supplies. The data wire interacts with the Arduino by sending the reading of the distance between
the OSV and the pool to it using its digital PWM pin. The third wire, the ground wire, simply but
safely brings electrical current to ground. The distance sensor was glued to the front of the OSV
so that as it will be able to effectively read the distance as the OSV gets closer to the pool.
The sensor used to receive the temperature of the pool of water was a digital sensor with
a probe that precisely measured and transmitted the temperature with the use of its implemented
1-Wire interface, which is a communication system that provides power and data transmission
between computers all with a single signal. The temperature sensor smoothly and easily interacts
20. 19
with the Arduino with three pins that connect to the microcontroller. The Arduino supplies a
power voltage of five volts, which one of the pins of the temperature sensor uses via a
breadboard to receive power to operate it. Another pin interacts with the Arduino by sending the
temperature reading to it. The last pin of the sensor is the ground pin. The temperature sensor is
fastened to the arm mechanism of the OSV. When the OSV effectively reaches the pool of water
with the help of the distance sensor, the arm lowers down into the pool and the temperature
sensor will have contact with the water and read its temperature.
A water level-sensitivity sensor was initially going to be used to start a timer that was a
critical factor in executing the bonus mission of calculating the depth of the pool of water. The
level-sensitivity sensor also interacts with the Arduino with three pins, one to receive power,
another to send readings, and the last one to send current to ground. The sensor would’ve been
also fastened to the arm mechanism of the OSV. As the OSV approaches the pool and the arm
lowers into it, the sensor, which is connected to the Arduino’s digital pins (meaning it will print
messages of only 0 and 1) would transmit a high signal (prints 1), meaning that it was in contact
with water. Once contact was made, the timer would start and then would stop once a push
button located at the bottom of the arm was pressed by the floor of the pool. With the time that
the arm spent in the pool and the velocity of the servo motor known, the depth of the pool could
be calculated with the following equation:
D = V*T or Distance = Velocity multiplied by Time.
Due to the lack of time and the unexpected complications on the programming side with the push
button, we weren’t able to use the water level-sensitivity.
The last sensor was a push button, which was intended to be used to end the timer described
above. It easily interacted with the OSV with three wires and an additional two for lighting an
LED. The three wires, like the other sensors, were used to receive power, transmit data, and send
current to ground. The push button was attached to the very bottom of the arm facing downward
so when the arm lowers all the way down to the ground, the push button would be pressed, and
the timer started by the level-sensitivity sensor would stop.
21. 20
Control Algorithm
1) FACESOUTH FUNCTION 2) NAVIGATETOBOTTOM WALL FUNCTION
3) FACE EAST FUNCTION 4) NAVIGATETO RIGHT WALL FUNCTION
5) FACE NORTH FUNCTION 6) NAVIGATETO POOLFUNCTION
Am I facing South?
No Yes
Turn right Do nothing
Am I at the bottom
wall?
NoYes
Move forwardDo nothing
Am I facing East?
No Yes
Turn left Do nothing
Am I at the right
wall?
NoYes
Move forwardDo nothing
Am I facing North?
No Yes
Turn left Do nothing
Am I at the pool?
NoYes
Move forwardDo nothing
22. 21
7) FACE POOLFUNCTION 8) NAVIGATETOWITHIN 250 MM OF POOLFUNCTION
9) WATER SAMPLING FUNCTION
In order to successfully avoid the obstacles throughout the mission area, our OSV will
first need to determine its orientation in the Landing Zone. The direction that the OSV is facing
will be determined by the overhead system and transmitted via RF to the Arduino on the OSV.
Our OSV will be programmed to turn towards the south wall, regardless of the orientation it is
originally placed in. It will continuously check its orientation as it turns to keep itself moving on
the desired path. Once its orientation is correctly facing the south wall, the OSV will be
programmed to travel towards it, turn east once it reaches the south wall, and travel to the x-
coordinate of the water while staying along the wall. We agreed it would be easiest to avoid the
Am I facing East?
No Yes
Turn right Do nothing
Am I at within 250
mm of the pool?
NoYes
Move forwardDo nothing
No
Yes
Lower arm Has the push button
been activated?
Begin measuring
water height and
temperature
Transmit data from
RF to computer
Figure 8
23. 22
Figure 9
obstacles on the mission area by having the OSV move alongside the south wall. Once our OSV
has reached the x-coordinate of the water, it will be programmed to turn north and travel to the
west side of the coordinates of the water pool (3250, 1700), turn east to face the pool, and stop.
Final Design Drawings
30. 29
ConstructionDetails
With the tough terrain that our team had to navigate through for our mission, we wanted to
prioritize the building quality of our vehicle. Staying true to our overall objective of constructing the
sturdiest vehicle out of all of the teams competing, we chose materials for the vehicle that we felt
were the best option. To start with the chassis, it was made solely out of plywood. Luckily, it proved
to be a very sturdy material, holding many components of our OSV. Plywood lined around the
perimeter of the actual chassis so that it could encapsulate all of the OSV components. Another two
pieces of plywood were added above the chassis so that the RF would be able to communicate
effectively. On the bottom of the chassis, there were four 3D printed motor housings attached at each
corner of the vehicle with four separate motors inside each of the housings. Attached to the motors
were four sturdy wheels we purchased off of an electronics website. We decided to go with buying
our wheels rather than building them, because we knew that the sandy terrain would be difficult for
the vehicle to navigate. The wheels we bought were about 60 centimeters in width, with rubber lining
throughout the treads, giving it the needed friction to handle the sand. On top of the chassis, we have
a mechanism that allowed for the temperature, water, and distance sensor to be position into the
water. An arm held all the sensors together in one clump, and that was powered to move with a rack-
and-pinion system. The system consisted of a continuous servo motor and a gear to allow the arm to
move either up or down. The construction of our vehicle was a crucial aspect to our vehicle’s success
in our overall mission, and in the end, we were all proud with our end product, despite the limited
time we had throughout the semester to work and finalize it.
31. 30
Final Bill of Materials
Item Manufacturer Vendor Model Number Description Mass (kg) Q uantity Cost
Arduino
Uno
Arduino ENES
Keystone
Office
A000066 - Supplies inputs from power supplies
- Transfers inputs and outputs to power
receivers
0.0280 1 $25.00
Battery
(9 V)
AccuPower Amazon B0084UXILQ - Current hours: 300 mAh
- Rechargeable
0.1788 1 $10.88
Battery
(12 V)
Tenergy Amazon 11606 - Current hours: 2000 mAh
- Rechargeable
0.2744 1 $23.92
Distance
Sensor
Sharp Amazon GP2Y0A21Y
K0F+cable
- Ability to track distance between 10
and 80 cm
0.0056 1 $12.90
Arm and
Holder
3-D Printer ENES
Keystone
Office
N/A - Perpendicular arm, intended to move
down into the poolof water.
.1034 1 $0.80
H-Bridge Arduino Adafruit 807 - Runs two DC motors with up to 600
mA per channel
- Comes with built in kick-back diodes
9.9 x 10-4
1 $2.50
Push
Button
Not specified Adafruit 560 - Weatherproof
- Shorts to the common contact when
pressed
N/A 1 $4.95
RF
Transmissi
on
Not known ENES
Keystone
Office
Not known - Able to transmit signals between sender
and receiver
0.030 1 $20.00
Servo
Motor
Parallax Parallax 900-00008 - Current:15 -200 mA
- Torque: 38 oz-in at 6 V
0.043 1 $13.99
Temperatur
e Sensor
Dallas
Semiconductor
SparkFun SEN-11050 - Sealed temperatureprobe measures
temperatures in wet environments
0.023 1 $ 9.95
Motor
Housing
3D Printing ENES
Keystone
Office
N/A -Stablized theposition of the motors
-Protected gears from sand and debris
0.022 4 $ 0.88
Voltage
Regulator
Major Brands Jameco TO-220FP - Can input voltage between 8.5-35 V
- Outputs 6V
N/A 1 $0.35
Water-
Level
Sensor
Phantom YoYo Amazon B00A1AEJ9M - The sensor is a circuit which is
completed when it reaches water
0.227 1 $9.99
Motors for
the Wheels
ServoCity SparkFun ROB-12285 - Voltage: 6 – 12 Volts
- Gear Ratio: 298:1
- Stall Torque: 40/70 oz-in. (6/12V)
0.068
(total)
4 $51.80
Wheels Not Specified SparkFun B007R9UMW
I
- Off road wheels
- Soft black rubber with deep tread
0.646
(total)
2 pair $29.90
Wood for
Chassis
Home Depot Home Depot 1502014 - Light, durable
- Plywood made from Pine
0.38 (mass
of wood
being put
on OSV)
1
boards
$6.69
TOTAL
MASS
1.97 TOTAL
COST
$241.25
32. 31
Product Performance Evaluation
The final product and evaluation of our vehicle was something our firm has looked
forward to since the start of the semester. By the time we had reached this point in the calendar,
we were, despite all the complications, very gratified by our end product. In retrospect, we
thought the design process would be linear and straightforward. However, we realized that the
process was very iterative. With regard to the specifications of our final product, we met the
requirements outlined in the mission. Our vehicle weighed below 3 kilograms, the footprint of
the vehicle was less than the maximum allowed, and we managed to attach a temperature sensor
and a depth measuring mechanism that could have potentially met the basic requirements. In
addition, our vehicle stayed under our $350.00 budget. Throughout the milestones, we managed
to make significant process on the performance of our vehicle, starting with the basic movements
of going forward and turning, and then later to incorporating the sensors we had. However, for
the actual mission, it did not turn out as well as we anticipated. The vehicle managed to
communicate with the RF communicator, but the vehicle failed during the navigation. During the
mission, the OSV failed to navigate to the pool of water, due to an issue with the motors.
A big drawback that led to these problems primarily stemmed from the build of the
motors, more specifically the gearbox that was attached to our motors. The gearbox was
extremely tiny, and with the amount of torque that the motors output, they broke very easily, so
we had to buy many sets of motors, even a couple weeks prior to our mission testing. By the time
we had to accomplish the mission, the vehicle had two nonfunctional motors, so we were relying
on the two working motors to power our vehicle and navigate to the pool, which ended up not
happening. If our company were allowed more time to further perfect our product, we definitely
would go back to the design process and evaluate what went well and what needed improvement.
Looking specifically at our preliminary vehicle, we felt that the structure and sturdiness of all the
components were up to our standards. However, some of the choices we made for the other
components, such as motors, needed to have been looked at more in depth so we didn’t run into
this particular problem, as well as possibly look into buying axles. Aesthetical, we felt that the
organization of what was placed on our chassis should have been looked over beforehand,
because when we finished our vehicle, the top of the chassis had a lot of components piled on so
that they didn’t fall off the vehicle. The addition of a perfboard would have been beneficial for
the final product because it would rectify any wiring issues. Using the breadboard proved to be
troublesome because wires were easily displaced from the circuitry, causing members of our firm
to continuously go back and correct the wiring.
Lessons Learned
Team Watergate took a lot away from this challenge. We as a group learned the
importance of organization and planning. We recognized early on that in order to take on a task
33. 32
of this size we could not simply do things by trial and error. To be able to plan accordingly it was
absolutely pivotal to have constant and clear communication for our team. Originally we lacked
this clear communication and this caused our productivity to suffer. However we quickly chose a
form of communication that worked for everyone in the group and we were able to return to
working in an effective manner. Some of the regrets members of our team had were not putting
more effort into the initial part of training. None of the members of our team had any prior
foundation in programming and therefore the information we received in training was crucial to
success in the navigation component of the mission.
Programming however was not the only part of training that team members learned and
wished they had focused more on. Everything from CAD to propulsion to the wiring of our OSV
was new to our members and the training we received prior to construction was the only
information most of us had on this subject. Another thing we as a group learned was that
theoretical does not always match with reality. Meaning the theoretical equations we learned in
training did not always directly translate exactly to the practical application. An example of this
was the propulsion aspect of our OSV. The equations we used to pick motors and batteries are
based on assumptions and do not factor in some real life factors. Something like the way the sand
is displaced, a battery not being fully charged or wear and tear on the axle can have a huge
impact on the OSV’s performance. Our OSV’s inability to complete the mission in the end in
fact came down to a failure of parts and so one final thing we learned is to have backups and to
prepare for the worst. We as a group found this challenge stimulating and to be a great learning
experience. The Watergate team members believe that the lessons they learned in this project
will be carried with them to many of the projects they participate on in the future.
Minutes
Wednesday, January 28
1st
meeting notes:
Members present: Everyone
Meeting Time: Tuesday at 7:00 at Hornbake lobby.
34. 33
Communication: Group Me
File sharing: Google Drives
Missions:
1. Water Sampling
2. Terrain Mapping
3. Metal Collection
4. Vent Detection
Goals: Well Crafted
Monday, February 2
Scribe - Melissa
Treasurer - Loyan
Financial plan -> spread money evenly
-> everyone download venmo app
3D printing:
Mon 2/2 - Andrew
Wed 2/4 - Daniel C.
Mon 2/9 - Melissa
Wed 2/11 - Jake
Mon 2/16 - Loyan
Wed 2/18 - Danielle
Mon 2/23 - Stephan
Wed 2/25 - Daniel L
Tuesday, February 3
Project Manager: Danielle
Team Name: Watergate
Milestone 1: Monday, February 23
1. Introduction and objectives of project
2. Team organization
Subsystem groups TBD
Rough idea of how we are splitting up project groups:
Danielle, Daniel & Dan good with Inventor
Andrew, Loyan, Stephan physical building
Jake has programming experience
3. TBD
35. 34
4. Each team member responsible for logging his/her progress, at the end we will compile
Gantt chart. Melissa and Dan in charge of final chart.
5. TBD
Paid ($350/8 = $43.75):
Danielle ✓
Daniel C ✓
Andrew ✓
Loyan ✓
Jake ✓
Daniel L. ✓
Melissa ✓
Stephan ✓
Thursday, February 12
Who attended:
-Melissa, Danielle, Loyan, Stephan
BOM:
Small spacers
Large spacers
Wheels (2) $.94
Wheels (2)
Organization:
Milestone 1 only Loyan, Stephan, Danielle, and Melissa presenting
Points 1&2: Loyan
Point 3: Danielle & Stephan mostly
Point 4: Melissa
Point 5: each person states own problem
Discussed potential designs of wheels and how we are measuring temperature.
DEADLINES:
2/17 - Points 1 and 2 due
2/18 - Finalize design and plan, check in with everyone, Point 4 due
2/19 - Everything finished
2/20 - Everything compiled
Sunday, February 15
Who attended:
- Daniel L, Daniel C, Danielle, Jake, Stephan, Andrew
36. 35
Today’s Scribe: Daniel L
3-D Printing:
Monday- Loyan is printing the sidewall, Danielle is printing the gears
Wednesday- Stephan is printing the motor housing.
Meeting Times:
Try to meet twice a week
Meet on a potential snowday
Wednesday After class
Design Concepts:
Idea 1:
Danielle’s idea
Flat platform on 4 wheels.
Tower rises perpendicularly above platform.
Arm extends parallel to platform over water.
Sensors Move down into water to measure temperature.
Water sensor records height of water.
Sensors move down to record depth
Dan’s idea:
Arm rotates into pool
Andrew’s idea:
Vehicle moves over pool.
Drive System:
Stephan and Jake research 5 pros and cons 2 wheel drive and 4 wheel drive systems by
Tuesday
Andrew research 5 pros and cons of treads by tuesday
Things to consider: tread, width, and material for wheels
Wheels: 2 Jake/Stephan
o Racing slicks (bald tires).
o Deflated tires (15-18psi)
o Pros of wide tires: better traction (grip).
o Cons of wide tires: bad for sharp steering, more mass = more work for motor.
o Pros of narrow tires: better steering; Cons = not as much traction.
o Conclusion: not too wide, not too narrow. About 3cm width, 2cm diameter.
o Jake: basically everything i found while doing my research. The only thing i
want to add is that we need some kind of tread on the tires (not completely
bald) so we can pass the 30 degree incline test.
o Jake: I also recommend we go on the wider side with wheels only because
the water is the farthest away
37. 36
Treads (I didn’t know if you guys wanted information on treads still since we’re likely
using wheels, but I’ll still put in info on what I found) Andrew
o Pros:
o Good Power Efficiency: High Performance and optimized traction system
o High traction
o Good on rough terrain
o Can support a heavy load; weight is more spread across the vehicle
o Cons:
o Lower speed
o Less maneuverability / requires more power
o Easily breakable
o Difficult to repair
Suspension Daniel
o Handling, braking, keep wheel in contact with sand
o F=-kx
o Attached to Chassis
o Would include springs and dampers
o Only reason to incorporate the system with your OSV is improved stability.
(Might not actually need) Completely up to us but seems like it will just
overcomplicate things for us.
Chassis Daniel
o Box that contains most of components, except the wheels.
o Supports weight and hold parts in their position.
o In automobiles usually made of sheet metal or plastic. For our OSV best
option is WOOD.
o This is because it is very sturdy, cheap and light.
o Ground Clearance: The space between the floor and the base of the vehicle.
Since the terrain consists of sand with a depth of 15-60mm above the rock
substrate, we should aim for a clearance in the range of 60-80mm or even
higher.This is so that the vehicle doesn’t sink in the sand. *The increased
height might affect the building of the arm though.
Arm
Thermometer Stephan
o I found a thermometer with an LCD display of the temperature reading and a
4 inch stainless steel probe that is attached to a five foot cable
o It measures temperatures from -40 to +200C. According to the mission
requirements, the water has a temperature in the range of -20 to +50C.
o Couldn’t find any cons about it. It’s $24.99. Link:
http://www.coleparmer.com/Product/Extech_TM25_Waterproof_Thermometer
_4_1_SS_Probe_9_2_Cable/UX-95001-
56?referred_id=778&mkwid=WXD7X8cZ&pcrid=49849374039&gclid=Cj0KE
QiA6ounBRCq0LKBjKGgysEBEiQAZmpvA0RbvDHXgoQzbjFN5QAPSfrTNW
Qb5YwwXs_xWwDz6nQaAhNw8P8HAQ
o If we use this thermometer, then we could use a pulley instead of a sliding
arm to lower the probe since it is attached to a cable.
Drivetrain Stephan
o 4-wheel drive is apparently the best for driving on sand, However with some
adjustments, 2-wheel drive could be just as efficient.
38. 37
o By deflating the tires to about 15-18 psi (or less if wheels are very narrow),
the wheels will “float” on the sand instead of sinking by driving a hard tire
through the sand. The avg. tire is pumped to about 32psi, so we will be
deflating a lot of air.
o Another adjustment is to switch tires with tread with “racing slick tires”. They
are basically bald tires. This also helps with preventing the car from sinking in
the sand.
o For the most part, 4 wheel drive vehicles are slightly better because they are
less likely to lose momentum, but with the above adjustments, we will be fine
with 2-wheel drive.
o Rear wheel drive will be better than front-wheel drive. Since the transmission,
thermometer, and arm will probably be close to the front, putting the motors
by the rear wheels will help to create a balanced vehicle in terms of weight.
This will help with better steering as well.
Steering Andrew Dan
o Turning Raduis = width/2 + wheelbase/sin(angle of front wheels)
o Differential System works by having one side spin its wheels faster than the
other.
Advantages: The OSV can turn without having to be moving forward
Disadvantages: Requires 4 wheel drive
o Steering systems usually pass through system of pivoted joints
o Two Types of Systems: Steering box system; rack-and-pinion system (the
second is probably easier to make)
o Rack-and-Pinion System: Joint is connected to a side of the axle closer to
one of the wheels, and pushing and pulling the joint will enable the front set of
wheels to steer either left or right
o (we can obviously
modify the design so that the vehicle is autonomous)
Power Jake
o (A little unsure of what type of batteries I am looking for but i think we want
something similar to RC battery packs)
o https://www.youtube.com/watch?v=xaSt_p0V6w0
39. 38
o Ni-Cd are cheap
very large discharge rate, dont hold for long time
cant run multiple times in one day without the performance degrading
o Ni-MH capable of holding higher voltage for longer time
higher capacity
2400 milliamp, but can increase a lot
o Li-Po batteries are the best but they are banned from this project (lithium
based)
o Conclusion: I think we should go with the Ni-MH batteries. I think they cost a
little more but the Ni-CD batteries dont seem reliable. The extra money
should pay off
o Ni-MH batteries lose battery while being stored (4% per day stored)
o Accoridng the wikipedia, they are used in different kinds of robot vacuums so
i see it as a good fit. They are commonly used in remote control cars
Mission performance Andrew
o Requirements: Must be able to be placed on a 30 degree incline without
sliding or tipping; must complete all base requirements in under 5 minutes
(get to the edge of water pool and within 250 mm; measure and transmit
water temperature; transmit to within 3 degrees celsius
o Location: (3250, 1700)
Navigation
Sensors Dan
o arduino accessories http://www.trossenrobotics.com/c/arduino-sensors.aspx
o IR analog distance sensor (20-150mm) $15
http://www.trossenrobotics.com/sharp-ir-distance-sensor-gp2y0a02yk.aspx
o Water sensor $4.95 http://www.trossenrobotics.com/sharp-ir-distance-sensor-
gp2y0a02yk.aspx
o Waterproof Thermometer $9.95 https://www.sparkfun.com/products/11050
Communication
Controls
Programming
o Melissa For measuring the temperature of the water I found this, didn’t fully
understand but I’m pretty sure it’s useful:
http://comoyo.github.io/blog/2013/08/01/m2m_adventures/
o Melissa Brief overview/gives you an idea of how we can code the OSV to
move http://communityofrobots.com/tutorial/kawal/how-make-your-first-robot-
using-arduino
Propulsion
Wheel Mechanics and Gear Motor Selection
What we want:
o Mass of 2kg total
o Wheel radius of 4cm
o Target speed= 0.1m/s
o 4 Wheel drive
4(Tw/ rw) – 4 (CRR*Lw) = 0
Lw= 2kg* 9.8m/s2
/4 wheels = 4.905 N
40. 39
(Tw/0.04m)- (0.3* 4.905N) = 0
Tw= 0.018 Nm
Torque Required: 2.6 oz-in
Target Velocity: 0.1 m/s
w = v/r = 0.1m/s / 0.04m= 2.5 rad/s
Angular Velocity Desired: 235.62 rpm
TE< 0.7(4.905 N)= 3.433N
Tw/rw< 3.433N
0.018Nm / 0.04 m < 3.433N
0.45N < 3.433N
Good! No Slip!
Our Battery: 75:1 micro mp
290 rpm 17oz-in stall torque
2.6oz-in = -17/290w +17oz-in
w = 245.65 rpm
Close to desired 2.35.62 rpm
water sensor
http://www.trossenrobotics.com/p/grove-water-sensor.aspx
Thursday, February 19th
Did more research on design and discussed who is doing what for MS1 presentation
Sunday, February 22nd
Finished MS1 powerpoint and practiced presentation
Tuesday, March 3rd
Who attended: Andrew, Jake, Danielle, Daniel L, Daniel C, Stephan
Scribe: Andrew
Daniel C: Caded the chassis; make out of wood; around 300 by 300 square mm base
Sensors Possibility (Danielle): Groove - Water Sensor, Temperature Sensor,
Get legit bill of materials so we can estimate weight and determine our true motor for the
OSV.
http://www.trossenrobotics.com/c/arduino-sensors.aspx - Several Arduino Sensors
1. 5 Motors (one motor for arm, one each wheel)
2. 4 Axles
3. Chassis
Already CAD’ed (Pine Wood)
Volume: 350mm*150mm*10mm
525,000mm^3
41. 40
.2625kg
4. 4 wheels
5. Motor Housing
6. Arm
7. Arm Support
8. Arduino
9. 3 Sensors
10.
Axles-http://www.lowrangeoffroad.com/rc-cars-upgrades/axial-axle-upgrades/ar60-ocp-rear-
axle-set-2-pcs.html
http://www.lowrangeoffroad.com/rc-cars-upgrades/axial-axle-upgrades.html
http://www.aliexpress.com/item/Moonshade-Wltoys-L959-L202-RC-Car-Spare-Parts-
Car-Front-Axle-L959-43/32290420516.html
Something I found for wheels while looking at axles-
http://www.rcplanet.com/RC_Car_Truck_Parts_s/5461.htm
Thursday, March 5th
Attended: Daniel L, Danielle, Daniel C, Andrew, Melissa
Made decision not to print wheels, purchasing wheels with larger diameter than we planned
Revised calculations for torque and speed to find a new motor that will work with these
wheels
PARTS TO BUY:
Distance Sensor: http://www.amazon.com/GP2Y0A21YK0F-Sharp-Distance-10-
80cm-
Compatible/dp/B00IMOSEJA/ref=sr_1_3?s=electronics&ie=UTF8&qid=1426216604
&sr=1-3&keywords=distance+sensor+arduino
Temperature sensor: https://www.sparkfun.com/products/11050
Wheels: https://www.sparkfun.com/products/10555
Batteries:
http://www.amazon.com/Tenergy-2000mAh-Battery-Leads-
Airplanes/dp/B00408X4LU/ref=sr_1_1?ie=UTF8&qid=1426204553&sr=8-
1&keywords=tenergy+12+v+2000+mah
http://www.amazon.com/Tenergy-Smart-Universal-Charger-
Battery/dp/B001AVUAVC/ref=pd_bxgy_t_img_y
Water sensor: http://www.amazon.com/Phantom-YoYo-Sensitivity-Water-
Sensor/dp/B00A1AEJ9M/ref=sr_1_10?ie=UTF8&qid=1425576702&sr=8-
10&keywords=water+sensor#product-description-iframe
http://www.amazon.com/gp/product/B00HTSL7QC/ref=pd_lpo_sbs_dp_ss_1?pf_rd_
p=1944687622&pf_rd_s=lpo-top-stripe-
1&pf_rd_t=201&pf_rd_i=B00A1AEJ9M&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=1P25
4S89JADFX5PFJRN7
42. 41
Motors for wheels
https://www.sparkfun.com/products/12285
Motor for arm
http://www.parallax.com/product/900-00008
Waterproof push button
http://www.adafruit.com/product/560 $4.95
H-Bridge $2.50
http://www.adafruit.com/products/807?gclid=CKqd_YqGn8QCFQUdgQodDagAGA
Loyan : Purchased: 4 wheels: $29:90
4 motors: $51:80
______________ Total: $81.70
Remaining Budget: $268.30
https://docs.google.com/a/terpmail.umd.edu/spreadsheets/d/1CDX_vVIm0aaonG_8Vb5qsJ
CDilzsalzkXzTYLaEUsh8/edit?usp=sharing
Meeting March 10
Worked on MS 2 to finalize
Battery for Arduino
http://www.amazon.com/AccuPower-Volt-Rechargeable-NiMH-
Battery/dp/B0084UXILQ/ref=sr_1_12?ie=UTF8&qid=1426029301&sr=8-
12&keywords=9v+NiMH+battery
Motor manufacturer
https://static.olark.com/jsclient-bucket1/follow.html
Voltage Regulator
http://www.jameco.com/1/1/25429-7806t-l-6v-1a-positive-voltage-regulator-220fp-3-pin-
analog-linear.html
Sunday, March 22nd
All parts ordered
Monday, March 23rd
Prototype Fabrication start
Started building chassis, using saw to cut out wood
3D printed motor housing 1
Working on pseudocode
Wiring temperature sensor
Wednesday, March 25th
Printed more motor housings
Working on pseudocode
43. 42
Started CADing arm
Testing temperature sensor
Thursday March 26th
Attendance: Loyan, Daniel C. and Stephan
Loyan and Stephan will continue basic readings for our sensors so that they have
been calibrated and will correspond with our objective and the programming that will
go into it.
Jake and Melissa will continue to work on the navigation program for the OSV. Try to
work with the tank to test the program since as of right now the OSV is not
operational.
Daniel C. and Daniel L. will continue with the axle and motor housing for the OSV,
and then constructing the OSV’s main frame.
Andrew will work on preparing the chassis, circuitry and wiring for the OSV.
Danielle will finish CADing the arm and meshing it to the gears. The rest of the group
will help her with applying it to the OSV.
Monday March 30
Info about H bridges: http://www.modularcircuits.com/blog/articles/h-bridge-secrets/h-
bridges-the-basics/
Wiring push button: http://www.arduino.cc/en/Tutorial/Pushbutton
Wiring temperature sensor:
http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Sensors/Temp/DS18B20.pdf
Wiring distance sensor:
http://www.tautvidas.com/blog/2012/08/distance-sensing-with-ultrasonic-sensor-and-
arduino/
Battery arduino adapter: http://store.cutedigi.com/9v-battery-snap-with-barrel-connector/
Sensor Readings
Water sensor - values range from 0 to 700. 0 when not in contact with water, ~680
when fully dipped in water.
Distance sensor - values range from 0 to 600. 0-1 when an object is far away and
600 when about 35 mm. When an object is closer than 35 mm to the sensor,
distance sensor reads below 100.
Push button - uses HIGH and LOW signals to turn LED on as well as to stop a timer
that is started when the water sensor is in contact with water.
Wednesday, April 1
Andrew absent
Daniel working on using an axle
Stephan Tiger Team hours to work on temperature sensor testing
Soldered motors
Friday, April 3
Andrew and Daniel and Stephan at open lab 4/3
printed motor housing, setting up motors
Dan made motors work in every direction
44. 43
Monday, April 6
Added sides to the frame of chassis to hold all wires, etc. in
Finished wiring motors to Arduino
Started coding navigation
Tuesday, April 7
Tiger team hours Melissa and Dan working on navigation code
Stephan working on temperature sensor testing. Temperature sensor not functioning
properly
Wednesday, April 8
MS 5: Unable to make OSV complete the tasks required
Spent time fixing code for MS5
Thursday, April 9
Daniel, Dan open lab water sensor testing
Got OSV to communicate with RF and navigate properly, received more points for MS5
Tiger Team hours Melissa and Dan working on navigation code
Friday, April 10
Dan, Daniel, Andrew open lab working on navigation code and fixing wheels and motors
Deciding against axle, used plastic in wheels
Monday, April 13
Working on navigation code
3D printed gear for arm
Wednesday, April 15
Working on navigation code
Friday, April 17
Open lab Danielle 3D printed arm, Dan there
Monday, April 20
Working on CADing new arm
Working on navigation code
Tuesday, April 21
Tiger Team hours Stephan working on temperature sensor, Andrew, Danielle setting up
arm, Melissa and Dan working on navigation code
3D printed new arm
Wednesday, April 22
MS6, OSV not approved for integration tests
Thursday, April 23
45. 44
Open lab Stephan gets arm and temperature sensing approved for MS5
Monday, April 27
Attaching new motors to OSV
Danielle and Dan at open lab testing code and arm
Tuesday, April 28
Tiger Team hours Stephan, Dan, Melissa, Daniel testing code and motors
Wednesday, April 29
Starting working on report
Working on navigation code
Thursday, April 30
Tiger Team hours Dan, Melissa code testing. Found out arduino is broken, got navigation
code to run successfully on another arduino
Monday, May 4
Andrew sick
Melissa, Dan working on code, Danielle working on report, replaced old arduino with new
one
Tuesday, May 5
Tiger team hours Dan, Melissa working on code. Motors not working but everything else
functions
Wednesday, May 6
MS7. Motors not fully functioning, OSV is unable to complete the mission.
Friday, May 8
Dan, Danielle go to open lab and attach new motors so that OSV can move. New motors do
not provide proper torque
Sunday, May 10
Danielle and Daniel meet to work on paper
Monday, May 11
Jake, Daniel, Dan, Andrew, Danielle Melissa working on paper
Friday, May 15
Danielle, Dan Lee, Stephan, Andrew, Jake work on MS8 MS9
Danielle and Dan Lee compile everything
