criticaldesignreviewcdr

25
Critical Design Report Submitted to: Inst. Richard C Busick GTA Jin Rong Yang Created by: Team P Garrett Greco Christine Li Sara Stacy Mike Zhang Engineering 1182 The Ohio State University Columbus, OH 20 April 2015

Upload: mike-zhang

Post on 15-Jan-2017

156 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: CriticalDesignReviewCDR

Critical Design Report

Submitted to:

Inst. Richard C Busick

GTA

Jin Rong Yang

Created by:

Team P

Garrett Greco

Christine Li

Sara Stacy

Mike Zhang

Engineering 1182

The Ohio State University

Columbus, OH

20 April 2015

 

Page 2: CriticalDesignReviewCDR

Executive Summary

The purpose of the AEV project was to introduce students to several aspects of project design and

allow them to explore the concepts of energy management and operational efficiency. The team had

to first complete several labs that gave them the skills necessary to build the AEV. Then, the team

continuously tested adjusted their AEV to improve efficiency while still completing the task stated in

the Mission Concept Review. The operational requirements of the AEV were to: start at the visitors

center, traverse to the entrance of the Jurassic Park, stop at the entrance gate and wait seven seconds

for it to open, navigate to the storage facility, pick up the caboose with the baby dinosaurs, traverse

back to the gate, wait seven more seconds, and return to the starting point. It was important for

students to be able to complete the operational objectives while innovating ways to increase the

efficiency of the vehicle because in the real world engineers have constraints to adhere to while

attempting to create a system with maximum efficiency.

The team used methods explored in lab to obtain their final AEV design and code. The first step was

for all team members to design a vehicle to be compared to both the other designs and a sample

design. Then, the team used concept screening and scoring to determine which vehicle they wanted

to continue testing. The most consideration was given to the vehicle design that demonstrated the

best comparable balance, weight, and efficiency. Once the team chose and built a vehicle, they used

that vehicle for the remainder of their testing. Various propellers and code configurations were then

tested for efficiency using calculations provided in lab. Once the team had an initial code, they

continuously made adjustments and re-tested the vehicle to achieve greater efficiency. However,

there were several setbacks during the final testing stages due to the wheel sensors and so the team

was unable to spend very much time improving the vehicle’s efficiency.

Based off of the the final AEV test, it was determined that the team did an adequate job adhering to

the operational objectives. The AEV completed the task stated in the mission concept review in under

two minutes and thirty seconds, which is all that was required of the vehicle. However, the vehicle

only had about average efficiency compared to the other vehicles tested in class. The major problem

that led to shortcomings in the vehicle’s efficiency was the wheel sensors. If the team had caught the

problem with the wheel sensors earlier in the testing stage, they most likely could have achieved a

higher efficiency score.

1

Page 3: CriticalDesignReviewCDR

Table of Contents

Introduction………………………………………………….……………………...…….……………....……………..

.…..…3

Experimental

Methodology………………………………………………………………………………………………....3-5

Results…………………………………………….….………………...…………………...………….…………...…....

........5-9

Discussion…………………….………....………………...…………………….….………....………………...………

….…10-17

Conclusion &

Recommendations…………………………….………....…………...……….……………………..15

Appendix………………………………………………….………....………………………...…………………….…...

....16 -23

2

Page 4: CriticalDesignReviewCDR

3

Page 5: CriticalDesignReviewCDR

Introduction

The objective of this lab was to make modifications to the code and AEV to make it more efficient

from the previous labs in addition to the operational requirements. This included stopping at the gate

and waiting 7 seconds, gently picking up the caboose, stopping at the gate for 7 seconds on the

return, and returning the the start in under 2.5 minutes. The team was able to make a successful run

and accomplished all the goals on its second run after changing the battery and conducting a few

tests. This report documents the design changes the team made in order to increase efficiency and

finish a successful run.

Experimental Methodology

First the team brainstormed design concepts and scored the member’s designs based on their

balance, weight, maintenance, cost, efficiency, and size. The materials available to use include the

mandatory Arduino board with the motor controllers (seen in Figure 1 below), battery, two types of

arms, two wheels, and two sensors. There was 4 available motors that could be used and two

propeller for each of the two propeller designs. Various body shapes, T, X, and rectangular as well as

many possible wing and smaller rectangular attachments.

Figure 1: Arduino board and Propellers

4

Page 6: CriticalDesignReviewCDR

After determining the best design, the team built and compared the design to a sample design. In the

initial stages of design, the team mainly familiarized itself with the Arduino commands and tested

various ways to get to reach the destination; this included learning and testing the difference between

the commands that use relative and absolute distances. The team also tested different ways to stop

the AEV before it reached the gate.

Next the team tested two different propeller shapes, one longer version and one shorter, square

version using the equipment shown below. This required a wind tunnel, speed controller, power

supply, thrust stand, and data acquisition system.

Figure 2: Wind Tunnel Equipment

The wind tunnel will help determine propulsion efficiency by measuring the power output to the

motor using a thrust stand. This data will be used in the future to calculate the propulsion efficiency

using the AEV analysis tool. The AEV analysis tool will allow the team to quickly create thrust vs.

voltage, power vs voltage, and power efficiency plots in the performance tests to determine the best

AEV and code to use.

5

Page 7: CriticalDesignReviewCDR

Figure 3: Final design of the AEV

Later the efficiency was tested and the design and code was modified again during the performance

tests. In the first performance test, the team will build a second AEV concept; the new model, Figure 3

above, was made to compare with the previous design, Figure 4 below in the results section, using a

test code and then found the propulsion efficiencies of both designs. The new model was determined

to be the most efficient of the two and was used in the final test run.

In the second performance test, the team focused on making a code that will successfully complete a

run on the while meeting the criteria. The team will brainstorm ideas on what speeds and suitable

amounts of power to use in the code as well as how to stop the AEV reliably. The code was completed

using experience from previous labs and continuous testing and tweaking on the track. In the final

performance test, the team worked on improving efficiency and compared energy costs before and

after the alterations.

6

Page 8: CriticalDesignReviewCDR

Results

Initially, the team developed a design from four brainstormed concepts and determined the best

design using both screening and scoring methods; this can be seen in Tables 1 and 2. The preliminary

design is shown below in Figure4. The main focus of this design was on balance. A T-shaped support

was chosen and place at the center of the AEV to balance the vehicle back to front; the base shape is a

cross shape, again promoting balance. Flat wings were placed on the sides of the AEV perpendicular

from the central location where the support arm was attached to the AEV. Motors were placed on the

wings at a distance to fit a 3-inch diameter propeller. The arduino was located at the back of the AEV

to provide separation from the front where the caboose would attach, avoiding the powerful magnet

at the front. The battery is located at the front of the AEV to balance the weight of the Arduino at the

back.

Figure 4: Preliminary Design for AEV

7

Page 9: CriticalDesignReviewCDR

Table 1: Concept Screening for Initial Designs

Success Criteria Reference Design A Design B Design C Design D

Weight 0 - + 0 0

Balanced 0 0 - 0 +

Maintenance 0 - + 0 +

Cost 0 - + 0 0

Efficiency 0 + - 0 +

Size 0 - - - 0

Sum +'s 0 1 3 0 3

Sum 0's 6 1 0 5 3

Sum -'s 0 4 3 1 0

Net Score 0 -3 0 -1 3

Continue? Yes No Yes No Yes

Table 2: Concept Scoring of Best 2 Designs A Reference Old Ref Design B Design D

Success

Criteria Weight Rat ing Weighted Score Rating

Weighted Score Rating

Weighted

Score

Weight 15% 3 0.45 4 0.6 3 0.45

Balanced 20% 3 0.6 2 0.2 4 0.8

Maintenance 10% 3 0.3 4 0.4 5 0.5

Cost 5% 3 0.15 5 0.25 3 0.15

Efficiency 40% 3 1.2 2 0.8 4 1.6

Size 10% 3 0.3 1 0.1 3 0.3

Total Score 3 2.35 3.8

Continue? No No Yes

8

Page 10: CriticalDesignReviewCDR

Through further comparative testing and more screening and scoring, the team developed a new AEV

design. The new design, however, it not that dissimilar to the original design. For this design, the focus

again was to maximize the balance of the AEV to ensure stabilization on the track. However, with this

design there was also a focus on weight shedding. The cross shaped base was replaced by a simple

rectangular base. The T-shaped support arm is replaced by the L-shaped, which had to be used in

order to fit the battery on the top of the base. The wings are located at the back of the AEV and tilted

upwards. The Arduino is located at the bottom of the base and again placed at the back of the AEV to

ensure enough distance between it and the magnet holder at the front.

Figure 5 Final Design for AEV

The costs for Design A and Design B are nearly the same. The most expensive part in the AEV was the

Arduino, which is $100. The arduino is most vital part in the AEV since it records commands and codes

from the computer and transmits them to external sensors and motors. The motors, battery,

propellers, wheel sensors, and support arm compromise the other costly parts of the AEV. Because

both AEV designs contain the same amount of essential parts, they cost nearly the same. Both AEVs

have the same count of each essential part, and the discrepancies in estimated cost come from the

lack of base building material Design B uses.

Equipped with the knowledge and experience from previous labs, the team was able to prepare the

AEV for the final test runs. In the first test run, the vehicle did not complete the run. In previous tests

9

Page 11: CriticalDesignReviewCDR

the AEV was running consistently, so the team expected the AEV to complete the run as it had been

previously. However, on the return trip the vehicle stopped short of the sensor so the gate was not

triggered. The team changed the battery and adjusted the code to the new battery before the second

run, and this fixed the problem.

Despite having completed the test run without having any points deducted, the team’s AEV was still

just barely in the bottom half of the class scores for efficiency (the test score sheet can be found in

the appendix) There are several factors that could have possibly contributed to the vehicle’s

performance. The team had several issues with the AEV’s wheel sensors in the weeks leading up to

the final test, and this kept them from being able to complete a final code until the day before testing.

Because the team took so long to finish coding the AEV, they were unable to continuously test it and

adjust the code to increase the efficiency. The vehicle was also one of the heavier AEVs, and it can be

noted that despite a few exceptions, the lighter AEVs performed better. The team however did place

very well compared to the other teams in terms of power to weight ratio. This is due to the reduced

weight and addition of a second motor.

The team specifically designed the code to reduce specific errors the teams noticed through the entire

semester while working with the AEV, especially with the loss of battery power and inconsistencies

between the two testing tracks. The code, in general, reduces the distance of unmarked coasting.

When coasting the AEV, the vehicle is more likely to be affected by battery loss and bumps in the

track. The code initially accelerates the AEV to a constant speed until a pre-determined distance is

reached. The AEV then coasts until another pre-determined distance is reached, then the AEV

reverses orientation of the motors and propels to a stop. This process was repeated for a total of four

sequences. There are some changes between the sequences. These include changes in the absolute

distance from the starting point, and changes in power and time of the reverse stop.

10

Page 12: CriticalDesignReviewCDR

Discussion

Table 1: Concept Screening

Success Criteria Reference Design A Design B

Weight 0 + +

Balanced 0 0 -

Maintenance 0 - +

Cost 0 - -

Efficiency 0 + 0

Size 0 - +

Sum +'s 0 2 3

Sum 0's 6 2 3

Sum -'s 0 3 2

Net Score 0 -1 1

Continue? N/A No Yes

Table 2: Concept Scoring

A Reference Old Ref Design A Design B

Success

Criteria Weight Rat ing

Weighted

Score Rating

Weighted

Score Rating

Weighted

Score

Weight 15% 3 0.45 2 0.3 2 0.3

Balanced 20% 3 0.6 4 0.8 4 0.8

Maintenance 10% 3 0.3 3 0.4 3 0.3

Cost 5% 3 0.15 2 0.1 4 0.2

Efficiency 40% 3 1.2 3 1.2 4 1.6

Size 10% 3 0.3 2 0.2 5 0.5

Total Score 3 3 3.7

Continue? N/A No Yes

The above tables break down the concept screening scores for the preliminary AEV and the final AEV.

Based off of the concept screening scores, the second only had negatives for cost and balance. The

preliminary design only scored better than the final design on balance due to the the T-Shape that

gave it more stability on the track. The concept scoring sheet shows that the second design performed

better in the efficiency and size categories. The second design was determined to have better

efficiency because of its smaller size and because testing showed the vehicle had a higher efficiency

score.

11

Page 13: CriticalDesignReviewCDR

Figure 6 Propulsion Efficiency vs. Advance Ratio with an EP-3030 propeller

Figure 6 shows the relationship between propulsion efficiency and advanced ratio. With the

increment of advance ratio, the propulsion efficiency is declining. This supports the inference that a

decrease in power provided to the motor increases the efficiency of propulsion, and therefore

increases the efficiency of the AEV in terms of energy usage. This graph should be taken with

skepticism, as the same plot with sample data produced a much different result, where propulsion

efficiency increased with advance ratio.

12

Page 14: CriticalDesignReviewCDR

Figure 7: Power Usage and Propulsion Efficiency of AEV over Final Run

Figure 7 above shows the power usage and propulsion efficiency of the AEV during the final test. The

AEV took little over 70 seconds to complete the entire track and all of the objectives that needed to

be completed. From the graph, four distinct rectangular boxes followed by four spike can be seen.

This is due to the programming of the AEV. The rectangular box of power used represents the

combined coding commands of acceleration and constant speed until a distance is reached. Once this

distance was reached, the AEV would break the motors, shown in the graph by no input of energy.

When the AEV would reach a designated distance, the motors would come back on, but be switched

to a reverse orientation and would propel backwards. This is the spike of energy usage which follows

the rectangular section. This process was, in essence, repeated four times: from start to gate, gate to

caboose, caboose to gate, and gate back to starting point. An increase in energy used can be observed

between the first two pairs of sections to the last two. This is due to the addition of the caboose,

which added more weight for the propellers to pull and therefore cause an increase in energy usage

for both the acceleration to constant speed and reverse stop. Throughout the graph of the efficiency

over time, the efficiency remains at a steady 12.25%, with occasional spikes during the coasting of the

AEV. This is most likely due to the AEV moving while having no power applied to the motors.

13

Page 15: CriticalDesignReviewCDR

Table 3: Energy Used Based on Various Phases

Phase Code Time Energy Used

1 reverse(4); //reverse all motors celerate(4,0,25,2); //accelerate all motors from 0 to 25% power in 2 seconds motorSpeed(4,25); //sets all motors at 25% power goToAbsolutePosition(335); // move 335 marks brake(4); // brake all motors goToAbsolutePosition(450); // move 450 marks

9.72 53.86

2 reverse(4); //reverse all motors motorSpeed(4,33); goFor(1); //continue for 1 seconds brake(4); //brake all motors goFor(7);//stop AEV for 7 seconds.

9.78 9.23

3 reverse(4); //reverse all motors celerate(4,0,25,2); //accelerate all motors from 0 to 25% power in 2 seconds motorSpeed(4,25); //sets all motors at 25% power goToAbsolutePosition(856); // move 856 marks brake(4); // brake all motors goToAbsolutePosition(973); // move 973 marks

9.24 52.18

4 reverse(4); //reverse all motors motorSpeed(4,30); //sets all motors at 30% power goFor(1); //continue for 1 seconds brake(4); // brake all motors goFor(7);//stop AEV for 7 seconds.

9.72 7.81

5 celerate(4,0,25,2); //accelerate all motors from 0 to 25% power in 2 seconds motorSpeed(4,30); //sets all motors at 30% power goToAbsolutePosition(700); // move 700 marks brake(4); //brake all motors goToAbsolutePosition(580); // move 580 marks

8.34 53.26

6 reverse(4); //reverse all motors motorSpeed(4,30); //sets all motors at 30% power goFor(1.5); //continue for 1.5 seconds brake(4); //brake all motors goFor(7); //stop AEV for 7 seconds.

10.26 13.97

7 reverse(4); //reverse all motors celerate(4,0,30,2); //accelerate all motors from 0 to 30% power in 2 seconds motorSpeed(4,30); //sets all motors at 30% power goToAbsolutePosition(180); // move 180 marks brake(4); //brake all motors goToAbsolutePosition(65); // move 65 marks

9.18 62.86

8 reverse(4); //reverse all motors motorSpeed(4,35); //sets all motors at 40% power 6.42 21.12

14

Page 16: CriticalDesignReviewCDR

goFor(1); //continue for 1 seconds

Total Time and Energy Used 73.74 273.49

The following equations were used to calculate the results in Figure 5 and Table 3. Sample calculations can be found in the appendix.

Time T = TE1000 Time (Seconds) = Time

measured/1000 (A1)

Current    I =   ( IE1024) * V R * ( 1 Amp

0.185 V olts)

Current (Amps) = (EEPROM Equivalent current (counts)/1024) * Arduino Reference Voltage (counts)

* Amp/Volts conversion

(A2)

Voltage  V =   102415   V* E Voltage (V) = 15 * EEPROM

equivalent voltage (counts) / 1024 (A3)

Power P = I * V Power Supplied (Watts, W) = Voltage (V) * Current (A)

(A4)

Incremental Energy

T )E = 2(P −P )1 2 * ( 1 − T 2

Incremental Energy = Average power supplied from two points /

Difference in time (A5)

15

Page 17: CriticalDesignReviewCDR

Table 4 Code Breakdown for Lab 10

Phase Code Time (seconds) Energy

(J)

1 reverse(4); //reverse all the motors

celerate(4,0,25,2); //accelerate motors from 0 - 25% power in 2

sec

motorSpeed(4,25); //sets all motors at 25% power

goToAbsolutePosition(335); // move (335 marks)

brake(4); // brake all motors

goToAbsolutePosition(479);// move 144 marks

11.64 45.86

2 reverse(4); //reverse all the motors

motorSpeed(4,30); //sets all motors at 30% power

goFor(1); //continue for 1 seconds

brake(4); //brake all motors

goFor(7); //continue for 7 seconds

8.22 7.300

3 reverse(4); // reverse all motors

celerate(4,0,25,2); //accelerate all motors from 0 to 25% power

in 2 seconds

motorSpeed(4,25); //sets all motors at 25% power

goToRelativePosition(355); // move 355 marks

brake(4); // brake all motors

goToRelativePosition(150); // move 150 marks

10.80 41.48

4 reverse(4); // reverse all motors

motorSpeed(4,30); // set all motors at 30% power

goFor(1); // continue for 1 second

brake(4); // brake all motors

goFor(3); // continue 3 seconds

6.96 6.582

5 celerate(4,0,25,2); //accelerate all motors from 0 to 25% power

in 2 seconds

motorSpeed(4,25) ;//sets all motors at 25% power

goToAbsolutePosition(336); // move 336 marks

brake(4); // brake all motors

goToAbsolutePosition(460); // move 124 marks

13.14 49.00

6 reverse(4); // reverse all motors

motorSpeed(4,32); // set all motors at 32% power

8.22 7.800

16

Page 18: CriticalDesignReviewCDR

goFor(1); // continue for 1 second

brake(4); //brake all motors

goFor(7); //continue for 7 seconds

7 reverse(4); // reverse all motors

celerate(4,0,25,2); //accelerate all motors from 0 to 25% power

in 2 seconds

motorSpeed(4,25); //sets all motors at 25% power

goToRelativePosition(355); // move 355 marks

brake(4); // brake all motors

goToRelativePosition(150);

15.30 60.92

8 reverse(4); // reverse all motors

motorSpeed(4,32); // set all motors at 32 % power

goFor(1); // continue for 1 second

brake(4); //brake all motors

goFor(3); // continue for 3 seconds

6.96 7.605

Total Time and Energy Used 81.24 226.55

The tables indicates the final and preliminary codes for AEV. Comparing the two data sets and codes

of Lab 10 (Table 2 above) and final test, it is evident that the previous code in Lab 10 was more

efficient in terms of its energy usage, using 226.55 J compared to 273.49 J used by the AEV in final

test. Though Lab 10’s data was built with two separate codes, it can be assumed that this would have

no effect on the data and that difference in the charge in the battery is negligible between the two

runs. Qualitatively, however, the team observed a much more consistent and accurate run in final test

than in the two from Lab 10. The AEV in final test consistently would follow a absolute position

command to the same position for every test. This accuracy is something that is much more desired

by the team from the AEV rather than efficiency.

17

Page 19: CriticalDesignReviewCDR

Conclusion and Recommendation

In the final test, the team tested the AEV with improved codes and brand new wheel sensors.

Compared to the test in lab 10, the AEV runs much smoother on the track. The AEV with new sensors

pauses at exact position where it needs to be stop, runs at a constant speed on the track and escorts

the caboose back to starting point safe and sound. There are two potential errors in this lab. One error which could affect the efficiency and performance

of the AEV is inconsistency / error in the wheel sensors. The wheel sensors play a huge part in terms

of performance of the AEV. The majority of the phases of the AEV code utilized the wheel sensors,

whether it was running the motors at a constant speed until a distance was reached or waiting until a

distance is reached before reversing. If there are any inconsistency with the sensor, the AEV can not

perform these commands at the right time. This is especially true for the situation of this track in

particular, which requires accurate placement of the AEV to open the gate, attach to the caboose and

land in the welcome zone.

Another error that can potentially occur is the loss of power in the battery over time. When fine

tuning the code to ensure the AEV runs smoothly and meets all the objective, the battery would

continue to lose power. Because of this power loss, each change that was made to the AEV

throughout the tuning and coding would become less and less accurate and time goes on. The effect

of battery loss is most noticeably observed in the reverse stop. As the remaining battery power would

lower and lower, the constant speed that the AEV would reach would be less than previous tests, as

the speed is actually a result of the percentage of power in the battery. This would affect the stop, as

the AEV would not carry as much speed as it would normally and would stop too quickly or even go

backward due to the reverse stop.

In order to reduce the cost of the vehicle, the team’s main strategy was to use as few parts as

possible. The main issue with this was getting the battery and the Arduino to fit on the vehicle

without the Arduino touching any metal pieces. However, the team was able to fit all necessary parts

on the AEV after some trial and error. Compared to the original design, the final design had fewer

parts and a more compact frame. This gave the final design the lowest overall cost of all designs

tested by the team.

In the final run, it is recommended that the team makes sure the sensors are properly working,

ensuring that the battery is charged, and the wheel sensor is counting correctly. The wheel sensor

plays an essential part in the test run because the goToAbsolutePosition() commands depend on the

wheel sensors’ accuracy. If the wheel sensors are not functioning, the distance marks that AEV

collects are not accurate, which will cause the vehicle to run inconsistently. The team needs to also

pay attention to the battery because the battery power will be declined after AEV runs two test runs.

18

Page 20: CriticalDesignReviewCDR

Appendix

Project schedule:

Member Tasks Role Start date Due date Percentage

completed

Garrett

Greco

Collect and process

data and charts

coder, graph

processor,

writer

3/12/2015 4/17/2015 100%

Christine

Li

Build second AEV

prototype, Complete

and edit design report.

AEV builder,

writer,

editor

3/12/2015 4/17/2015 100%

Mike

Zhang

Edit code for Arduino,

create concept

solidwork graph for

AEV, Notebook

coder,

SolidWork

grapher, writer

Notebook

Checker

3/12/2015 4/17/2015 100%

Sara

Stacy

Writing and edit lab

report and summary

AEV builder,

writer, recorder

3/12/2015 4/17/2015 100%

19

Page 21: CriticalDesignReviewCDR

SolidWorks model

Estimated weight: 0.251 kg

Estimated cost: $153.4

20

Page 22: CriticalDesignReviewCDR

Testing Score Sheet

21

Page 23: CriticalDesignReviewCDR

Sample Calculations

Time

T=TE1000

T = 64821000

T = 6.482

Time (Seconds) = Time measured/1000 (A1)

Current

I = IE1024*VR*1

Amp0.185 Volts

I = (88 counts1024) *

2.46 * 1 Amp0.185

Volts

I = 1.1427 A

Current (Amps) = (EEPROM Equivalent current

(counts)/1024) * Arduino Reference Voltage

(counts) * Amp/Volts conversion

(A2)

Voltage

V = 15 * VE1024

V = 15 * 530

counts1024

V = 7.7637 V

Voltage (V) = 15 * EEPROM equivalent voltage

(counts) / 1024 (A3)

Power

P=IV

P = 7.7637 V * 1.1427 A

P = 8.8718 W

Power Supplied (Watts, W) = Voltage (V) *

Current (A) (A4)

Incremental Energy

E=(P1-P2)2(T1-T2)

E = 8.8718 + 7.48862 *

(6.482 - 6.362)

E = 0.9816

Incremental Energy = Average power supplied

from two points / Difference in time (A5)

22

Page 24: CriticalDesignReviewCDR

Code

reverse(4); //reverse all motors

celerate(4,0,25,2); //accelerate all motors from 0 to 25% power in 2 seconds

motorSpeed(4,25); //sets all motors at 25% power

goToAbsolutePosition(340); // move 340 marks

brake(4); // brake all motors

goToAbsolutePosition(455); // move 455 marks

reverse(4); //reverse all motors

motorSpeed(4,33);

goFor(1); //continue for 1 seconds

brake(4); //brake all motors

goFor(7);//stop AEV for 7 seconds.

reverse(4); //reverse all motors

celerate(4,0,25,2); //accelerate all motors from 0 to 25% power in 2 seconds

motorSpeed(4,25); //sets all motors at 25% power

goToAbsolutePosition(856); // move 856 marks

brake(4); // brake all motors

goToAbsolutePosition(973); // move 973 marks

reverse(4); //reverse all motors

motorSpeed(4,30); //sets all motors at 30% power

goFor(1); //continue for 1 seconds

brake(4); // brake all motors

goFor(7);//stop AEV for 7 seconds.

celerate(4,0,25,2); //accelerate all motors from 0 to 25% power in 2 seconds

motorSpeed(4,30); //sets all motors at 30% power

23

Page 25: CriticalDesignReviewCDR

goToAbsolutePosition(725); // move 725 marks

brake(4); //brake all motors

goToAbsolutePosition(605); // move 605 marks

reverse(4); //reverse all motors

motorSpeed(4,30); //sets all motors at 30% power

goFor(1.5); //continue for 1.5 seconds

brake(4); //brake all motors

goFor(7); //stop AEV for 7 seconds.

reverse(4); //reverse all motors

celerate(4,0,30,2); //accelerate all motors from 0 to 30% power in 2 seconds

motorSpeed(4,30); //sets all motors at 30% power

goToAbsolutePosition(200); // move 200 marks

brake(4); //brake all motors

goToAbsolutePosition(90); // move 90 marks

reverse(4); //reverse all motors

motorSpeed(4,35); //sets all motors at 35% power

goFor(2); //continue for 2 seconds

24