Materials Team

MS9
December 14th, 2018
ENES100, 0601

TABLE OF CONTENTS

0
 1

Approvals______________________________________________________________2
Executive
Summary_______________________________________________________3
Introduction_____________________________________________________________
4
Primary Design Shortcomings______________________________________________6
Final Design Details______________________________________________________7
Final Design
Drawings___________________________________________________14
Construction Details_____________________________________________________15
Final Bill of Materials___________________________________________________15
Projects Management____________________________________________________16
Disposal Plan__________________________________________________________17
Product Performance and Evaluation_______________________________________17
Lessons Learned________________________________________________________18
Appendix
Minutes_________________________________________________________19
Navigation Code_________________________________________________22

Approvals

Name Signature Contribution

Asbah Shafi Asbah Shafi Created the basic format for
the report, assigned roles.
Worked on Preliminary
Shortcomings, OSV
Mission, and disposal plan

1
 2

section.
Robert Henry Robert Henry Completed CAD drawings
for OSV and Claw
Mechanism. Did
calculations for the
propulsion.

Andrew Tran Andrew Tran Calculations with wheels

and motors; basic
propulsion and navigation;
power
Nick Vece Nick Vece Wrote the construction and
testing plan.

Lauren Skramko Lauren Skramko Summary, introduction,

design details, editing and
formatting of the report.
Zhiyue Gao Zhiyue Gao Created CAD drawings and
contributed to design
details.

Nicholas Good Nicholas Good Worked on the Preliminary

Billing chart and the Gantt
Chart, assisted with the
Executive summary
Jessica Nah Jessica Nah Wrote the sections for
Sensors and Actuators,
Control Algorithm, and
Product Performance and
Evaluation. Also created

2
 3

the control algorithm and

Rohith Krishnamoorthy
Rohith Krishnamoorthy
its diagram.
Worked on the Project
management section,
learned lessons, minutes,
and disposal plan.

Executive Summary
Our firm was assigned a mission to design a small cost effective Over Sand
Vehicle (OSV) to be deployed on a Pacific Island to survey the area where aircraft debris
has washed ashore. The OSV has specifically been tasked to navigate to the debris and
test whether the material is steel or copper and transmitting that data back to mission
control. Along with that main mission, there are additional missions such as lifting the
debris entirely off the ground as well as weighing the debris and sending the weight back
to mission control.
When the OSV lands in a random orientation in the landing zone of the island, it
must orient itself and navigate through rocky and sandy terrain while avoiding obstacles
to reach the mission site. Our OSV uses a four wheel drive system and Arduino code to
navigate through the sandy terrain. At the mission site, the OSV was planned to use a
magnetic sensor attached to the claw on our OSV to determine if the material was either
steel or copper. A magnetic sensor was chosen because steel is more magnetic than
copper. To complete the additional objectives we had planned to use the claw to pick up
the debris and weigh the material using a weight sensor. Using RF communications, the
OSV will send the details of its survey back to mission control.
The creation of our OSV involved a lot of calculations, coding and general
engineering to make the OSV run as intended. Power and torque calculations were done
in order for the wheels, motors and battery to work efficiently together. Coding was done

3
 4

for the control algorithm to allow our vehicle to navigate around the obstacles to the
mission site. Lastly our firm had to assemble our vehicle in order to have a final product.
To test our designs and their success all the firms had to compete in a competition
at the end of the semester. In these runs our OSV had the necessary code to navigate the
field, but due to some hardware and software issues we were unable to demonstrate it on
the field. We also weren’t able to accomplish the mission objectives. For one, the servo
mechanism intended to control the claw had burnt out during testing, thus making the
claw no longer functional. Because the claw was no longer functional, it could not pick
up objects and weigh the material. For the mission objective of identifying the material,
the magnetic sensor did not arrive in time for it to be implemented.

Introduction
Our team was part of an engineering firm competing with other firms to build the
best Over Sand Vehicle (OSV). The OSV was to be small and inexpensive, but complex
and autonomous enough to carry out various tasks on a remote island in the Pacific
Ocean, where aircraft debris have washed ashore. Our team specifically was focused on
material identification, and our mission was to navigate within 250 mm of the aircraft
debris, measure and transmit the type of material present and confirm that the transmitted
material type is correct. Moreover, we were given advanced objectives of acquiring the
debris by lifting it entirely off the sand and determining the mass of the debris to within
20 g and transmitting the result.
There were specific guidelines that we had to follow in regards to the structure,
power, performance, communication, control and navigation, safety, and cost of the
OSV. The mass of the OSV was limited to be no more than 2.5 kg, and the body and
propulsion system of the OSV had to fit within a 300 x 300 mm footprint. Also, the OSV
needed a 100 x 100 mm tracking marker with a 15 mm white border placed on the top of
it. Additionally, the OSV needed to be controlled by an Arduino compatible
microcontroller and be able to navigate to a specified point within ± 250 mm. In addition,
the budget of our team had to be restricted to be under $350.

4
 5

The OSV was constructed using a variety of skills and software. Parts of the OSV
was designed through CAD and 3D printed, along with premade parts bought online and
attached to the vehicle. An Arduino Uno was also used to program the OSV, as well as
for the wiring on the breadboard mounted onto the OSV. Our vehicle was designed to
have a four wheeled design, using proximity sensors and RF communications to navigate
the obstacles. In order to achieve our missions we used the claw mounted on the front of
the OSV, and this claw would test for the material using a magnetic sensor, pick up the
debris and weigh it using a weight sensor, all mounted onto the claw.
To achieve our goal, the team was split into two subgroups: a programming group
and a mechanics/design group. Each team had their own specialty, either writing the code
for the OSV or physically assembling the vehicle during each meeting. By explicitly
dividing the roles into two subgroups, our team was able to effectively design the vehicle
and work together to find solutions via close communication through meetings and online
chat. Overall, however, we had to work together, making sure the code reflected the way
the vehicle was being built, and that both the design and the code agreed with one
another.

Primary Design Shortcomings

While making our first set of designs we encountered many challenges in both our
mission as well as our design limitations that we had to overcome to finish our final
design. Regarding mechanics, originally we chose four uxcell mini 12V motors, however,
there were errors in our calculations so when we actually implemented the motors, the
speed of our vehicle exceeded the requirements moving at 1.2 m/s. Thus we realized that
we needed to order new motors with a lower velocity so that the OSV could run on the
course without kicking sand back. In addition, we ran into problems with the construction
of the vehicle. When ordering the wheels for our OSV, we failed to realize that they were
shipping from China which guaranteed that they wouldn’t come in time for any of our
milestones, thus setting us back. To remedy this we needed to find new wheels which
were quickly found and implemented into our tight design schedule. The wheels were

5
 6

slightly different dimensions so as a result we had to recalculate torque and power. We

then constructed the base model of our vehicle, however, we still had to meet the design
requirement that the vehicle must fit in a 300x300 mm dimensions. Due to the increased
wheel width, the chasis area did not fit these dimensions so we had to reconstruct the
OSV by trimming the chassis to fit the size requirement.
For programming changes we had to make a lot of refinements in our detailed
control algorithm. During editing we found that our approach in coding was flawed and
we had to restructure our entire code to be operational. This required finding a way to
link the code controlling the motors with the navigation and sensor code. While the
algorithm was able to run in simulation, there was difficulty in establishing the circuitry
between the code and the physical OSV. Due to the addition of the motor shield and
finding that new pins needed to be added, the circuitry of the OSV had to be modified
from the preliminary design. Additionally, we had planned to use one proximity sensor at
the center of the OSV, but we learned that due to the sensor’s range limitation we needed
to add an additional sensor. This required placing a sensor on the left and right side of the
front of the OSV thus requiring us to modify our navigation and sensor code. This also
required modifications to our circuitry which greatly complicated our design we needed
to find a way to use the pins in a way that the motor shield could link the arduino,
sensors, and battery in a workable circuit. Lastly, our initial design included an inductive
proximity sensor to distinguish between copper and steel materials, however this
wouldn’t work the way we had initially thought and thus we had to change our approach.
Instead we opted for a magnetic sensor which could detect the magnetic field metals.
Since steel is magnetic and copper is not, we used this as a basis to distinguish materials.
Sadly, due to confounding variables such as shipping dates, we were unable to acquire
this sensor in time to implement this idea.

Final Design Details

Structure:

6
 7

Figure 4: This is the CAD model of our

claw mechanism that we will attach
onto our OSV. This detailed model is
useful as we plan to use this model to
3D print this piece.

Our team’s OSV fits within the

required of 300x300 mm box to
determine our length and width as well
as weighing under the required 2.5 kg.
For the materials of our OSV, the
rectangular chassis is made out of a ¼
inch thick piece of plywood that is 20x 18 mm long, and the wheels are made of 3D
printed PLA parts and 119mm in diameter. The dimensions of our entire OSV is
275x265mm and lastly, our OSV weighs in at 1.78 kg.

7
 8

Figure 5: This figure illustrates the placement of the parts on the chassis of the
OSV.

Figure 8:
Drawing for
the Claw.

Propulsion:

Figure 6: This graph depicts the line formed by the relationship between the stall torque
and the no load speed. The equation of the line is y=(-0.555)x+ 41.6

The wheels for our

OSV use paddle buggy
tires and have a diameter of 12
cm and a width of 4.2 cm. We
believe that the paddle system

8
 9

will have enough traction to move across the sand effectively. Refer to Figure 5 regarding
placement. The motors being used have a stall torque of 41.6 oz-in while its no load
speed is at 75 rpm. Using the relationship between the torque and the angular velocity, as
seen in figure 5, and knowing that the minimum torque required is 10.67 oz-in, we can
find the maximum angular velocity. This came out to be 35.7 rpm or 0.595 rev/s. The
maximum linear speed of the OSV would then be 0.224 m/s.
Regarding performance, the OSV is able to run on normal tile. It is able to turn
and move forward and back. However, it is unable to properly move in the sand. This
could be due to errors in our choice of motors. The wheels are unable to overcome the
force of friction produced by the sandy terrain.

OSV Mission
The mission we have been tasked with is the materials mission, which entails
reaching the mission site across rocky terrain and then correctly determining the material
present at the site. The navigation code was developed and implemented onto our arduino
uno which would control the movement of our motors to allow our OSV to traverse the
track. Alongside the main objective, determining weather the debris is steel or copper,
there are two additional objectives which entail weighting the debris as well as lifting the
debris entirely off the ground. Our team planed to achieve every mission objective, and
designed our OSV with all these objectives in mind. We planed to transmit the material
correctly through the use of a magnetic sensor attached to the claw of our OSVs, as steel
is much more magnetic than copper. For the additional objectives we planed to use the
claw on the front of the OSV which could pick up and weigh the debris by use of a
weight sensor. We planned on making the claw functional enough to lift the debris by use
of a servo and a pulley-like system without making our OSV top heavy and tipping over.

Power:
The motors we decided to use on our OSV are four electric Cytron motors. The
decision was made after calculating the amount of torque needed for our OSV. The 12V,

9
 10

600mA max current motor is a brushed DC geared motor and it will utilize the Arduino
Motor shield to rotate in different directions. The motor can be run at a lower voltage, but
the torque will be lowered as a result.
To accompany the four DC motors, a motor shield is needed to control the speed
and direction of the motors independently. The motor shield is stackable onto our
Arduino Uno and allows the wiring to be simplified, preventing a nest of wires. With all
of the components in the OSV, it is important to make sure the wiring of all the
components are organized and easy to track, and that can be done with the motor shield.
All of the components were powered by a 12V 2000mAh Tenergy NiMH battery
pack. The battery pack was wired to a switch which controlled all the power for the OSV.
The switch was then wired into a breadboard that powered the Arduino and Motor Shield.

Sensors and Actuators

To successfully travel the terrain, our team decided to use two Ultrasonic
Proximity sensors in order to relay information to the OSV about any objects in its path.
To perform the mission, we planned to use a HX711 Load Cell Amplifier load sensor to
measure the mass of the debris, a Hall Effect KY-003 Magnetic Sensor to detect what
material the debris is, and a servo mechanism to operate the claw and pick up the
material. All of these sensors are compatible with the Arduino microcontroller.
The Ultrasonic Range Sensor uses ultrasonic waves to detect movement or
measure distances. For the communication system, this module has 4 pins, Ground, VCC,
Trig and Echo. The Ground and VCC pins of the module need to be connected to the
Ground and 5 Volt pins on the Arduino board. The Trig and Echo pins for the sensor on
the left side of the OSV were connected to the Arduino Uno’s Digital I/O pins 10 and 11,
and the right sensor’s Trig and Echo pins were connected to pins 12 and 13.

10
 11

Figure 7: This figure depicts our circuit diagram for implementing one of our proximity
sensors in relation to our Arduino Uno. Source: https://howtomechatronics.com/
tutorials/arduino/ultrasonic-sensor-hc-sr04/

The servo mechanism unfortunately burnt out during testing, therefore making the
claw inoperable. We were thus unable to implement the load sensor onto our
dysfunctional claw. Lastly, the magnetic sensor did not arrive in time for it to be utilized.

Control Algorithm:
In order to navigate to the mission site, our OSV used the command centers’
provided information of current OSV coordinates, current OSV heading, and mission site
coordinates to determine what direction the mission site is in. As outlined below in
Figure 9, the OSV will rotate towards that direction and move forward until its ultrasonic
proximity sensors sense an object 190 mm ahead in its path. The OSV will compare its
current coordinates with the mission coordinates to determine whether it is outside the
range of the mission site. If so, the object is an obstacle, and the OSV will turn 45
degrees toward the center and move forward for two seconds. The vehicle will proceed to
re-orientate itself to face the mission site again and move forward, repeating this process
until the OSV reaches the mission site and detects the material.
Upon reaching the mission site, the OSV will use the Ultrasonic Proximity Sensor
to adjust to an optimal location to identify and pick up the material. To determine

11
 12

whether the material is copper or steel, the claw was to have a magnetic sensor attached,
along with a load sensor. If the material is magnetic, the sensor will send information to
the OSV, allowing the vehicle to determine it is steel. Otherwise, the OSV will infer that
the material is copper, a non-magnetic material. Afterwards, the OSV will use the servo
to move the claw to pick up the material, allowing the load sensor to return information
on the material’s mass for the vehicle to transmit to the command center, finally
completing the mission.

Figure 9: This figure depicts the thought process in coding our Arduino's moving
patterns. In this flowchart you can clearly see how the OSV plans to maneuver through
the course.

FINAL DESIGN DRAWINGS

12
 13

Construction Details
The motor casings were attached to the undercarriage of the chassis using screws
to hold them in place. The casings were tightened around the motors, and then the 3D-
printed wheels were fastened to the motors. The motor wires were all fed up to the power
source throw a central hole drilled into the chassis. Using adhesive velcro, the battery was

13
 14

secured on top of the chassis in the back right hand corner. To connect the ultrasonic
sensors to the front of the chassis, a they were each soldered into half of a breadboard
which was taped to the chassis. A switch was soldered to the battery, and then a
breadboard was used so that all of the power being input to the arduino in order to power
the OSV was being run through the switch. Lastly, our claw was mounted regardless of
its functionality with a 3D printed structure hot glued to the chassis to keep our claw
hanging high enough off of the ground. The claw was attached to two support structures
along with the servo.

Final Bill of Materials

Final bill of materials. Provide your final bill of materials. Include all major and
minor parts on your OSV. As appropriate, include manufacturer, vendor, model
number, description, mass, and cost. Indicate the total final cost.
Listed below is our final bill of materials, including the manufacturer, vendor and
model number as provided.

Part and specs Cost

Tenergy 12V 2000mAh NiMH Battery Pack $115.03

Plywood Sheet 12”x.25”x12” $10.20

Adafruit Arduino v2.3 Motor Shield $18.90

Hilitchi Arduino Stackable Pins $13.99

WINOMO 10A Switch $4.99

CAMWAY High Torque Servo $9.93

50kg Half bridge Load Cell from Geekstory $10.75

Motors(4) $59.92
Vetco Ultrasonic Sensors VUPN5786(2) $24.59

$268.30

14
 15

Project Management
For project management, we decided to divide the team into two subteams:
Programmers and Mechanics. Leading the programming team was Asbah Shafi and
Robert Henry lead the mechanics team. This allowed us to specialize and focus on key
aspects of constructing the OSV. It also allowed us to effectively collaborate with each
other because each team was an expert on the aspects of the OSV. To organize our tasks
to complete we used the following gantt chart:

However, we realized that we found difficulty in following the gantt chart due to
challenges presented as we constructed the vehicle. These challenges are outlined in the
lessons learned section. To resolve this, we had to push back deadlines due to many
confounding variables such as parts not arriving on time, realizing that programming and
circuitry is a difficult task and not having the right motors. All of these variables in
addition to others noted in the lessons learned section changed our preliminary schedule.
For example the aspect of programming the vehicle to make it autonomous
required a lot of trial and error. So while the physical vehicle was being constructed by
the mechanics team, the programming team dedicated their time to coding the proximity,

15
 16

load and magnetic sensors and navigation. In addition, creating the circuitry also took
quite some time. The circuitry not only required aspects of programming the arduino but
also the mechanics such as communicating the microcontroller with the motors.

Disposal Plan
As we dismantle our OSV the parts will be disposed of in one of three ways. The
wheels, motors, and sensors will all be given to the ENES 100 graveyard box as they can
be useful to teams in the future. The arduino microcontrollers may also go to the
graveyard box given that they are not burnt out, otherwise they will be properly disposed
of and recycled. The wood we used on our vehicle as well as the 3D printed plastic parts
can all be recycled. Lastly our battery must be thrown away as it can no longer be used.

Product Performance and Evaluation

Our OSV fits the product specifications, as it weighs 1.78 kg, has dimensions of
275x265, and costed $268.30. Our vehicle is also able to navigate toward the mission site
and move according to the instructions of the navigation code. The OSV is able to run on
normal terrain, however, due to the placement of the sensors and the sandy terrain, it is
unable to do so properly within the sandbox. In addition, the OSV lacked a functioning
magnetic sensor and servo, and could not identify the material or perform the advanced
objectives of picking up the material and measuring its mass.
Design changes that would have improved the OSV’s performance could include
placing the proximity sensors higher so that it would not mistake the sand as an object as
the OSV traveled across the miniature dunes of the sandbox. Another change would be to
increase the speed of the vehicle to allow it to drive itself through the sand more easily
and overcome the sand’s hills. We would also need to adjust the voltage powering the
servo, so that the mechanism would not burn out again, and would be able to maneuver
the claw properly.

Lessons Learned

16
 17

During the span of the semester, our team has learned important lessons about
engineering and the many complications that come along with it. The complex process of
engineering design and turning the design into reality was tedious and time-consuming,
requiring multiple instances of trial and error. We ran into numerous amounts of issues
along the way, however, as we overcame each issue. we learned the lessons of the
importance of communicating, properly ordering materials, and compromising in
measures.
Since our group consisted of 9 members, communication among the group was
essential. During Milestone 2, no one communicated and no progress was made on
writing the huge paper over the weekend before it was due. After we realized the urgency
of the assignment and the presentation was rushed to be finished hours before the
deadline, our team has actively kept communicating in our chat to ensure even
contribution. If our team had a chance to start over again, we would be better at
communication. We should not assume that not responding means that you don’t have to
contribute to the greater project. We would increase the amount of communication in
person and actively respond to each other.
All materials used to build our OSV had to be purchased by our group and because
of this, we learned how to properly order materials. We learned that we needed to
efficiently and carefully order our parts and not to order more than required and to, as
well as properly researching each more before purchasing the materials. We accidently
ordered materials from China which caused them to arrive past certain deadlines. We also
initially ordered an incorrect battery and motor, without doing the proper calculations. If
we were given the opportunity to start over, we would certain take more care into
ordering our parts.
When putting together our OSV, we learned that the building process is not as
exact as the design drawings are and that we have compromise with our measurements.
When we attached our motors and wheels to the base of the OSV, our OSV went over the
350 x 350 mm footprints. To adjust the dimensions, we had to reprint our wheel axles and
motor housings to a smaller size. We also spent a lot of time sanding down and using a

17
 18

drill to get the parts to the right dimensions. We would originally print it to the axles to a
shorter length and would not be as opposed to making these changes. The trial and error
of these parts consumed way too much time because we hesitated on making our
changes.
Overall, our team learned a lot about the engineering design process as well as the
trials and tribulations that come along with it. Engineering design includes a combination
of a lot of different skills, which stresses the importance of a team to achieve a finished
product. Each member of our team has taken away major lessons from this project when
it comes to the design process. The OSV project was a perfect microcosm as in
introduction into the engineering world and the lessons our team has taken away will
shape us into our engineering futures.

Appendix:

Minutes:

Tuesday, September 4
We met each other
Thursday, September 12
Began coming up with ideas for the design of our OSV
Friday, September 13
Continued developing our rough idea for a design
Tuesday, September 18
Began working on Milestone 1 - The Project Development Plan Presentation
Thursday, September 20
Ordered parts for OSV online
Tuesday, September 25
Milestone 1 Turned In
Tuesday, September 27

18
 19

Began Working on Milestone 2 - Preliminary Design Presentation

Tuesday, October 2
Began Working on Milestone 3 - Preliminary Design Report
Thursday, October 4
Finished up the presentation adding details such as locomotion system, mission system,
power system, and navigation strategy
Tuesday, October 9
Turned in Milestone 2
Thursday, October 11
Finished up the report by adding in CAD sketches
Began construction of OSV
Friday, October 12
Turned in Milestone 3
Tuesday, October 16
Began programming and wiring of OSV
Provided an updated physical resources worksheet to indicate what parts are in hand,
what is in transit with receipts, and what is not yet purchased.
Thursday, October 18
Turned in Milestone 4
Tuesday, October 23
We 3d printed necessary parts and added them to OSV
Thursday, October 25
Prepared for forward locomotion test, turning test, RF communications test, navigation
base objective, and mission base objective.
Tuesday, October 30
Submitted Milestone 5
Thursday, November 1
Began coming up with ways to successfully complete the navigation integration test
Tuesday, November 6

19
 20

Began coming up with ways to successfully complete reconnaissance mission integration

test
Thursday, November 8
Completed navigation integration test
Tuesday, November 13
Completed reconnaissance mission integration test
Thursday, November 15
Demonstrated Milestone 6
Tuesday, November 20
Began Milestone 7 - Product Demonstration
Tuesday, November 27
Continued progress on our OSV tasks
Thursday, November 29
Began writing final report (Milestone 9 - Final Design Report)
Tuesday, December 4
Began Milestone 8 - Final Design Poster Presentation
Thursday, December 6
Completed rough draft and started proofreading and editing
Friday, December 7
Went to open lab hours to finish Milestone 7 and get as much credit as possible
Thursday, December 13
Completed Milestone 8 and 9
Friday, December 14
Turned in Milestone 8 and 9
Completed team evaluation

Navigation Code
#include "Enes100.h"
#include "Enes100Simulation.h"
#include "DFRTankSimulation.h"

20
 21

//motors
#include <Wire.h>
#include <Adafruit_MotorShield.h>
#include "utility/Adafruit_MS_PWMServoDriver.h"

/* Create a new Enes100 object

* Parameters: string teamName, int teamType, int markerId, int rxPin, int txPin
*/
Enes100 enes("Italy's Planes Can't Wake Up", DEBRIS, 13, 8, 9);
Adafruit_MotorShield AFMS = Adafruit_MotorShield();
Adafruit_DCMotor *topLM = AFMS.getMotor(1);
Adafruit_DCMotor *botLM = AFMS.getMotor(2);
Adafruit_DCMotor *botRM = AFMS.getMotor(3);
Adafruit_DCMotor *topRM = AFMS.getMotor(4);

double dest_x,dest_y;
double loc_x,loc_y,loc_theta;

//distance sensors pins

const int trigPinL=10;
const int echoPinL=11;
const int trigPinR=12;
const int echoPinR=13;
long duration;
int distancemm;
int finished=0;

void setup() {
pinMode(trigPinL,OUTPUT);
pinMode(echoPinL, INPUT);
pinMode(trigPinR, OUTPUT);
pinMode(echoPinR, INPUT);

Serial.begin(9600);
AFMS.begin();

// Retrieve the destination

while (!enes.retrieveDestination()) {
enes.println("Unable to retrieve location");
}

dest_x=enes.destination.x;
dest_y=enes.destination.y;

enes.print("My destination is at ");

enes.print(dest_x);

21
 22

enes.print(",");
enes.println(dest_y);

//initial location
if(enes.updateLocation()){
loc_x=enes.location.x;
loc_y=enes.location.y;
loc_theta=enes.location.theta;
enes.print("Initial x coordinate: ");
enes.println(loc_x);
enes.print("Initial y coordinate: ");
enes.println(loc_y);
enes.println("Initial heading: ");
enes.println(loc_theta);
}
else{
enes.println("Unable to update location");
}
}

void loop() {

while(finished==0){
// Retrieve the destination
while (!enes.retrieveDestination()) {
enes.println("Unable to retrieve location");
}

dest_x=enes.destination.x;
dest_y=enes.destination.y;

// Update the OSV's current location

if (enes.updateLocation()) {
loc_x=enes.location.x;
loc_y=enes.location.y;
loc_theta=enes.location.theta;
enes.print("My x coordinate is ");
enes.println(loc_x);
enes.print("My y coordinate is ");
enes.println(loc_y);
enes.print("My theta is ");
enes.println(loc_theta);
} else {
enes.println("Couldn't update my location");
}

//calculate distance to mission site, angle to face mission site, and radians we need to turn

22
 23

double distance = pow(pow(dest_x-loc_x,2)+pow(dest_y-loc_y,2),.5);

double angle = asin((dest_y-loc_y)/distance);
double turn = loc_theta-angle;

if(turn>0){
//turn right until heading matches angle
while(enes.location.theta>angle+.05){
turnRight();
while(!enes.updateLocation());
}
}
else if(turn<0){
//turn left until heading matches angle
while(enes.location.theta<angle-.05){
turnLeft();
while(!enes.updateLocation());
}
}

//stop moving
brake();

//move forward until object detected or in range of mission site

moveForward();
do{
while(!enes.updateLocation());
loc_x=enes.location.x;
loc_y=enes.location.y;
}while(!objectDetected());
//&&!nearDest(loc_x,dest_x,loc_y,dest_y));--> redundant to check if near mission site?
brake();

//check if near destination (material detected)

//move within mission site
if(nearDest(loc_x,dest_x,loc_y,dest_y)){
moveForward();
do{
while(!enes.updateLocation());
loc_x=enes.location.x;
loc_y=enes.location.y;
distance = pow(pow(dest_x-loc_x,2)+pow(dest_y-loc_y,2),.5);
}while(distance>.1);
brake();
finished=1;
enes.println("Navigation complete");
}
//otherwise avoid obstacle

23
 24

else{
avoidObstacle();
}
}

enes.navigated();
// Transmit the material of the debris
// The type of the number passed must be a double
enes.baseObjective(STEEL);
// Transmit the mass of the debris
enes.bonusObjective(2.43);

//if within 200 mm of mission site

boolean nearDest(double loc_x,double dest_x,double loc_y,double dest_y){
double distance = pow(pow(dest_x-loc_x,2)+pow(dest_y-loc_y,2),.5);
//return true if near dest
if(distance<.2){
return true;
}
return false;
}

//get distance from sensors

float getDistance(int trigPin,int echoPin){
digitalWrite(trigPin,LOW);
delayMicroseconds(2);
digitalWrite(trigPin,HIGH);
delayMicroseconds(10);
digitalWrite(trigPin,LOW);
duration=pulseIn(echoPin,HIGH);
distancemm=(duration*0.034/2)*10;
return distancemm;
}

//if either sensor detects an object within 190 mm

boolean objectDetected(){
float distanceL=getDistance(trigPinL,echoPinL);
float distanceR=getDistance(trigPinR,echoPinR);
//object within 190 mm of either sensor
if(distanceL<190||distanceR<190){
return true;
}
return false;
}

24
 25

void avoidObstacle(){
double angle;
if(enes.updateLocation()){
loc_y=enes.location.y;
}

//in upper quadrant, turn right 45 degrees

if(loc_y>1){
angle=enes.location.theta-(3.14159/4);
turnRight();
while(enes.location.theta>angle+.05){
while(!enes.updateLocation());
}
}
//in lower quadrant, turn left 45 degrees
else{
angle=enes.location.theta+(3.14159/4);
turnLeft();
while(enes.location.theta<angle-.05){
while(!enes.updateLocation());
}
}

//move forward for 2 seconds

moveForward();
delay(2000);
brake();
}

void moveForward(){
//set speed (0-255)
topLM->setSpeed(120);
botLM->setSpeed(120);
topRM->setSpeed(120);
botRM->setSpeed(120);

topLM->run(FORWARD);
topRM->run(FORWARD);
botLM->run(FORWARD);
botRM->run(FORWARD);
}

void brake(){
topLM->run(RELEASE);
topRM->run(RELEASE);
botLM->run(RELEASE);
botRM->run(RELEASE);

25
 26

void turnLeft(){
//lower speed (0-255)
topLM->setSpeed(60);
topRM->setSpeed(60);
botLM->setSpeed(60);
botRM->setSpeed(60);

topLM->run(BACKWARD);
topRM->run(FORWARD);
botLM->run(BACKWARD);
botRM->run(FORWARD);
}

void turnRight(){
//lower speed (0-255)
topLM->setSpeed(60);
topRM->setSpeed(60);
botLM->setSpeed(60);
botRM->setSpeed(60);

topLM->run(FORWARD);
topRM->run(BACKWARD);
botLM->run(FORWARD);
botRM->run(BACKWARD);
}

26