ms9_design_report__daniel edits (1) (1)

60
Waterga te Milestone 9 May 18 th , 2015 ENES100, 0502

Upload: daniel-lee

Post on 07-Jan-2017

146 views

Category:

Documents


3 download

TRANSCRIPT

Page 1: MS9_Design_Report__Daniel Edits (1) (1)

WatergateMilestone 9

May 18th, 2015

ENES100, 0502

Page 2: MS9_Design_Report__Daniel Edits (1) (1)

Table of ContentsApprovals.....................................................................................................................................................2

Executive Summary.....................................................................................................................................3

Introduction.................................................................................................................................................4

Preliminary Design Shortcomings................................................................................................................7

Final Design Details......................................................................................................................................8

Structure..................................................................................................................................................8

Propulsion...............................................................................................................................................9

OSV Mission...........................................................................................................................................13

Power....................................................................................................................................................15

Sensors..................................................................................................................................................16

Control Algorithm..................................................................................................................................17

Final Design Drawings................................................................................................................................19

Construction Details..................................................................................................................................24

Final Bill of Materials.................................................................................................................................24

Product Performance Evaluation...............................................................................................................24

Lessons Learned........................................................................................................................................25

Minutes.....................................................................................................................................................26

Figure 1......................................................................................................................................................10Figure 2......................................................................................................................................................11Figure 3......................................................................................................................................................11Figure 4......................................................................................................................................................12Figure 5......................................................................................................................................................13Figure 6......................................................................................................................................................14Figure 7......................................................................................................................................................15Figure 8......................................................................................................................................................21Figure 9......................................................................................................................................................22Figure 10....................................................................................................................................................22Figure 11....................................................................................................................................................23Figure 12....................................................................................................................................................24Figure 13....................................................................................................................................................25Figure 14....................................................................................................................................................26Figure 15....................................................................................................................................................27

1

Page 3: MS9_Design_Report__Daniel Edits (1) (1)

Figure 16....................................................................................................................................................28

2

Page 4: MS9_Design_Report__Daniel Edits (1) (1)

Approvals

Name Signature Contribution

Stephan Appiah

Daniel Callow

Melissa Davis

Loyan Eyow

Andrew Jones

Danielle Karpa

Daniel Lee

Jason Mallon

3

Page 5: MS9_Design_Report__Daniel Edits (1) (1)

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.

4

Page 6: MS9_Design_Report__Daniel Edits (1) (1)

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

5

Page 7: MS9_Design_Report__Daniel Edits (1) (1)

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.

6

Page 8: MS9_Design_Report__Daniel Edits (1) (1)

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

7

Page 9: MS9_Design_Report__Daniel Edits (1) (1)

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 Design Shortcomings

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

8

Page 10: MS9_Design_Report__Daniel Edits (1) (1)

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

9

Page 11: MS9_Design_Report__Daniel Edits (1) (1)

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

10

Page 12: MS9_Design_Report__Daniel Edits (1) (1)

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

11

Page 13: MS9_Design_Report__Daniel Edits (1) (1)

Figure 4

PropulsionOverview: 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.

12

Page 14: MS9_Design_Report__Daniel Edits (1) (1)

2XW

2X

OSV FBD:

∑ F x=4∗TE−4 RR=0 4 ( τ w

rw)−4 (CRR∗Lw)=0

τ w=torquerequired for the wheel ¿overcomerolling resistance

Lw=weight oneach individual wheel

τ w=CRR∗Lw∗Rw

τ w=( .3 )( (1.97 ) (9.81 )4 ) (0.06 m )=0.087 N∗m=12.32 oz−¿

Once we found the torque required to overcome the rolling resistance we used our desired

velocity to calculate our target RPM.

V = 0.2m/s

ω= vr= 0.2

0.06=3.33 rad

s=31.8rpm

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.

13

T F

FN

FRR

FNFigure 5

Page 15: MS9_Design_Report__Daniel Edits (1) (1)

τw

τw<μLw

0.087 N∗m0.06 m

<(0.7)( 1.7 kg∗9.814

)

1.45 N<2.92 N

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.

Figure 7

14

Motor Characteristic

DC Gear Motor

Micro Gear motor - 90 RPM (6-12V)

ROB-12285 ROHS

https://www.sparkfun.com/products/12285

Page 16: MS9_Design_Report__Daniel Edits (1) (1)

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.

Y=mx+b

T=mω+b

m=0−4045−0

N∗mrpm

b=.4 N∗m

τ=(−4045 )ω+40

Withthe required torque of τ=12.32 oz−¿ , our speed will was ω=31.1 rpm

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

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 MissionThe batteries that had exposed leads for recharging were required to be equipped with

connectors at all times.

15

Page 17: MS9_Design_Report__Daniel Edits (1) (1)

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.

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

16

Page 18: MS9_Design_Report__Daniel Edits (1) (1)

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.

PowerTo 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

17

Page 19: MS9_Design_Report__Daniel Edits (1) (1)

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

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

18

Page 20: MS9_Design_Report__Daniel Edits (1) (1)

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.

Control Algorithm

1) FACE SOUTH FUNCTION 2) NAVIGATE TO BOTTOM WALL FUNCTION

19

Do nothingTurn right

YesNo

Am I facing South?

Do nothing Move forward

Yes No

Am I at the bottom wall?

Page 21: MS9_Design_Report__Daniel Edits (1) (1)

3) FACE EAST FUNCTION 4) NAVIGATE TO RIGHT WALL FUNCTION

5) FACE NORTH FUNCTION 6) NAVIGATE TO POOL FUNCTION

7) FACE POOL FUNCTION 8) NAVIGATE TO WITHIN 250 MM OF POOL FUNCTION

20

Do nothingTurn left

YesNo

Am I facing East?

Do nothing Move forward

Yes No

Am I at the right wall?

Do nothingTurn left

YesNo

Am I facing North?

Do nothing Move forward

Yes No

Am I at the pool?

Do nothingTurn right

YesNo

Am I facing East?

Do nothing Move forward

Yes No

Am I at within 250 mm of the pool?

Page 22: MS9_Design_Report__Daniel Edits (1) (1)

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

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

21

Transmit data from RF to computer

Begin measuring water height and

temperatureHas the push button

been activated?Lower arm

Yes

No

Figure 8

Page 23: MS9_Design_Report__Daniel Edits (1) (1)

Figure 11

22

Page 24: MS9_Design_Report__Daniel Edits (1) (1)

Figure 12

23

Page 25: MS9_Design_Report__Daniel Edits (1) (1)

24Figure 14

Page 26: MS9_Design_Report__Daniel Edits (1) (1)

25Figure 15

Page 27: MS9_Design_Report__Daniel Edits (1) (1)

26

Figure 16

Page 28: MS9_Design_Report__Daniel Edits (1) (1)

Construction Details

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.

27

Page 29: MS9_Design_Report__Daniel Edits (1) (1)

Final Bill of MaterialsItem Manufacturer Vendor Model Number Description Mass (kg) Quantity 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 GP2Y0A21YK0F+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 pool of 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 Transmission

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

Temperature Sensor

Dallas Semiconductor

SparkFun SEN-11050 - Sealed temperature probe measures temperatures in wet environments

0.023 1 $ 9.95

Motor Housing

3D Printing ENES Keystone Office

N/A -Stablized the position 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 B007R9UMWI

- 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

28

Page 30: MS9_Design_Report__Daniel Edits (1) (1)

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

29

Page 31: MS9_Design_Report__Daniel Edits (1) (1)

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: EveryoneMeeting Time: Tuesday at 7:00 at Hornbake lobby.

30

Page 32: MS9_Design_Report__Daniel Edits (1) (1)

Communication: Group MeFile sharing: Google DrivesMissions:1.   Water Sampling2.   Terrain Mapping3.   Metal Collection4.   Vent DetectionGoals: Well Crafted

Monday, February 2

Scribe - MelissaTreasurer - Loyan

Financial plan -> spread money evenly-> everyone download venmo app

3D printing:Mon 2/2 - AndrewWed 2/4 - Daniel C.Mon 2/9 - MelissaWed 2/11 - JakeMon 2/16 - LoyanWed 2/18 - DanielleMon 2/23 - StephanWed 2/25 - Daniel L

Tuesday, February 3

Project Manager: DanielleTeam Name: Watergate

Milestone 1: Monday, February 23

1. Introduction and objectives of project 2. Team organizationSubsystem 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

31

Page 33: MS9_Design_Report__Daniel Edits (1) (1)

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: LoyanPoint 3: Danielle & Stephan mostlyPoint 4: MelissaPoint 5: each person states own problem

Discussed potential designs of wheels and how we are measuring temperature.

DEADLINES:2/17 - Points 1 and 2 due2/18 - Finalize design and plan, check in with everyone, Point 4 due2/19 - Everything finished2/20 - Everything compiled

Sunday, February 15

Who attended:- Daniel L, Daniel C, Danielle, Jake, Stephan, Andrew

32

Page 34: MS9_Design_Report__Daniel Edits (1) (1)

Today’s Scribe: Daniel L

3-D Printing:Monday- Loyan is printing the sidewall, Danielle is printing the gearsWednesday- Stephan is printing the motor housing.

Meeting Times:Try to meet twice a weekMeet on a potential snowdayWednesday After class

Design Concepts:

Idea 1:Danielle’s ideaFlat 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 tuesdayThings to consider: tread, width, and material for wheels

Wheels: 2 Jake/Stephano 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

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

33

Page 35: MS9_Design_Report__Daniel Edits (1) (1)

o Pros:o Good Power Efficiency: High Performance and optimized traction systemo High tractiono Good on rough terraino Can support a heavy load; weight is more spread across the vehicleo Cons:o Lower speedo Less maneuverability / requires more powero Easily breakableo Difficult to repair

Suspension Danielo Handling, braking, keep wheel in contact with sando F=-kxo Attached to Chassiso Would include springs and damperso 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 Danielo 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=Cj0KEQiA6ounBRCq0LKBjKGgysEBEiQAZmpvA0RbvDHXgoQzbjFN5QAPSfrTNWQb5YwwXs_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 Stephano 4-wheel drive is apparently the best for driving on sand, However with some

adjustments, 2-wheel drive could be just as efficient.

34

Page 36: MS9_Design_Report__Daniel Edits (1) (1)

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 Dano 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 jointso 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 Jakeo (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

35

Page 37: MS9_Design_Report__Daniel Edits (1) (1)

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 Andrewo 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.aspxo IR analog distance sensor (20-150mm) $15

http://www.trossenrobotics.com/sharp-ir-distance-sensor-gp2y0a02yk.aspxo Water sensor $4.95 http://www.trossenrobotics.com/sharp-ir-distance-sensor-

gp2y0a02yk.aspxo 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 SelectionWhat we want:o   Mass of 2kg totalo   Wheel radius of 4cmo   Target speed= 0.1m/so   4 Wheel drive4(Tw/ rw) – 4 (CRR*Lw) = 0 Lw= 2kg* 9.8m/s2/4 wheels = 4.905 N

36

Page 38: MS9_Design_Report__Daniel Edits (1) (1)

(Tw/0.04m)- (0.3* 4.905N) = 0Tw= 0.018 Nm  Torque Required: 2.6 oz-inTarget Velocity: 0.1 m/sw = v/r = 0.1m/s / 0.04m= 2.5 rad/s

Angular Velocity Desired: 235.62 rpm TE< 0.7(4.905 N)= 3.433NTw/rw< 3.433N0.018Nm / 0.04 m < 3.433N0.45N < 3.433N Good! No Slip!Our Battery: 75:1 micro mp290 rpm 17oz-in stall torque2.6oz-in = -17/290w +17oz-in w = 245.65 rpm    Close to desired 2.35.62 rpm

water sensorhttp://www.trossenrobotics.com/p/grove-water-sensor.aspxThursday, February 19thDid more research on design and discussed who is doing what for MS1 presentation

Sunday, February 22ndFinished 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 Axles3. Chassis

Already CAD’ed (Pine Wood) Volume: 350mm*150mm*10mm525,000mm^3

37

Page 39: MS9_Design_Report__Daniel Edits (1) (1)

.2625kg4. 4 wheels5. Motor Housing6. Arm7. Arm Support8. Arduino9. 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 plannedRevised 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-iframehttp://www.amazon.com/gp/product/B00HTSL7QC/ref=pd_lpo_sbs_dp_ss_1?pf_rd_p=1944687622&pf_rd_s=lpo-top-stripe-

38

Page 40: MS9_Design_Report__Daniel Edits (1) (1)

1&pf_rd_t=201&pf_rd_i=B00A1AEJ9M&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=1P254S89JADFX5PFJRN7

Motors for wheelshttps://www.sparkfun.com/products/12285

Motor for armhttp://www.parallax.com/product/900-00008

Waterproof push buttonhttp://www.adafruit.com/product/560 $4.95

H-Bridge $2.50http://www.adafruit.com/products/807?gclid=CKqd_YqGn8QCFQUdgQodDagAGA

Loyan : Purchased: 4 wheels: $29:90                               4 motors: $51:80                               ______________ Total:  $81.70Remaining Budget: $268.30 https://docs.google.com/a/terpmail.umd.edu/spreadsheets/d/1CDX_vVIm0aaonG_8Vb5qsJCDilzsalzkXzTYLaEUsh8/edit?usp=sharing

Meeting March 10

Worked on MS 2 to finalize

Battery for Arduinohttp://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 Regulatorhttp://www.jameco.com/1/1/25429-7806t-l-6v-1a-positive-voltage-regulator-220fp-3-pin-analog-linear.html

Sunday, March 22ndAll parts ordered

Monday, March 23rdPrototype Fabrication startStarted building chassis, using saw to cut out wood3D printed motor housing 1Working on pseudocodeWiring temperature sensor

Wednesday, March 25thPrinted more motor housings

39

Page 41: MS9_Design_Report__Daniel Edits (1) (1)

Working on pseudocodeStarted CADing armTesting temperature sensor

Thursday March 26thAttendance: 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 30Info 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/PushbuttonWiring temperature sensor:http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Sensors/Temp/DS18B20.pdfWiring 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 1Andrew absentDaniel working on using an axleStephan Tiger Team hours to work on temperature sensor testingSoldered motors

Friday, April 3Andrew and Daniel and Stephan at open lab 4/3printed motor housing, setting up motors

40

Page 42: MS9_Design_Report__Daniel Edits (1) (1)

Dan made motors work in every direction

Monday, April 6Added sides to the frame of chassis to hold all wires, etc. inFinished wiring motors to ArduinoStarted coding navigation

Tuesday, April 7Tiger team hours Melissa and Dan working on navigation codeStephan working on temperature sensor testing. Temperature sensor not functioning properly

Wednesday, April 8MS 5: Unable to make OSV complete the tasks requiredSpent time fixing code for MS5

Thursday, April 9Daniel, Dan open lab water sensor testingGot OSV to communicate with RF and navigate properly, received more points for MS5Tiger Team hours Melissa and Dan working on navigation code

Friday, April 10Dan, Daniel, Andrew open lab working on navigation code and fixing wheels and motorsDeciding against axle, used plastic in wheels

Monday, April 13Working on navigation code3D printed gear for arm

Wednesday, April 15Working on navigation code

Friday, April 17Open lab Danielle 3D printed arm, Dan there

Monday, April 20Working on CADing new armWorking on navigation code

Tuesday, April 21Tiger Team hours Stephan working on temperature sensor, Andrew, Danielle setting up arm, Melissa and Dan working on navigation code3D printed new arm

Wednesday, April 22MS6, OSV not approved for integration tests

41

Page 43: MS9_Design_Report__Daniel Edits (1) (1)

Thursday, April 23Open lab Stephan gets arm and  temperature sensing approved for MS5

Monday, April 27Attaching new motors to OSVDanielle and Dan at open lab testing code and arm

Tuesday, April 28Tiger Team hours Stephan, Dan, Melissa, Daniel testing code and motors

Wednesday, April 29Starting working on reportWorking on navigation code

Thursday, April 30Tiger Team hours Dan, Melissa code testing. Found out  arduino is broken, got navigation code to run successfully on another arduino

Monday, May 4Andrew sickMelissa, Dan working on code, Danielle working on report, replaced old arduino with new one

Tuesday, May 5Tiger team hours Dan, Melissa working on code. Motors not working but everything else functions

Wednesday, May 6MS7. Motors not fully functioning, OSV is unable to complete the mission.

Friday, May 8Dan, Danielle go to open lab and attach new motors so that OSV can move. New motors do not provide proper torque

Sunday, May 10Danielle and Daniel meet to work on paper

Monday, May 11Jake, Daniel, Dan, Andrew, Danielle Melissa working on paper

Friday, May 15Danielle, Dan Lee, Stephan, Andrew, Jake work on MS8 MS9Danielle and Dan Lee compile everything

42

Page 44: MS9_Design_Report__Daniel Edits (1) (1)

43