Critical Design Review: Lab Report

Submitted to: Dr. Bixler

GTA Omar El-Khoury

Created by: Team B

Josh Burton

Brook Cannon Vivian PAng

Kyle Slavinski

Engineering 1182

The Ohio State University Columbus, OH

December 6th, 2016

Executive Summary The galactic empire hired a group of engineers to develop an advanced energy vehicle (AEV) that will be used to transport R2D2 units from their assembly station to their final destination. The AEV utilized an advanced networking system, akin to a monorail, as a logistical aid. The planet on which the AEV functions is remote and limited in power supply. Thus, the engineers were to develop the AEV so that energy consumption was efficiently managed. Additionally, limiting total expenses accumulated during development was of utmost importance. The AEV had to also meet certain design constraints in both its software and its physical construction. Due to the remote planet’s shifting faults, the monorail system may accumulate perturbations. Therefore, the AEV was required to maintain operational consistency despite any changes that occurred on the track. The engineers were required to create a scaled model of such an AEV that met the operational requirements, design constraints, and minimized the energy/mass ratio. Leading up to choosing the final AEV design, three performance tests were performed, which respectively focused on AEV concept designs, AEV code designs, and energy optimization. During the first performance test, two distinct AEV prototypes were designed using Solidworks and were physically constructed in a laboratory setting. Several design characteristics were considered throughout the design process, such as center of gravity, durability, cost, or adaptability. Screening and scoring matrices were created, from which the best design was chosen. Specifically, the first design featured two propellers situated in the back of the AEV in a pusher configuration The second design featured a pusher bi-directional pusher configuration by situating the propellers on both ends of the AEV. The energy efficiency of each AEV was deduced based on observing the resulting power vs time plots after each run. From this data, the second concept design was determined to be used for future tests. During the second performance test, the team designed two unique sets of code for the AEV. Each set of code was designed to allow the AEV to complete the mission at hand. Like the first performance test, the two code designs were tested for AEV energy efficiency. However, due to time constraints, only one design was tested to completion. The team was unable to gather sufficient data to choose a design based on experimental observation. As such, the first design was chosen to be used in further testing, as it was the most refined. This design featured the use of absolute position functions, as it allowed the team to accurately discern the position of the AEV. Additionally, the code made use of increased coasting to reduce unnecessary energy use. The Performance Test Three largely involved making minor changes to the code and physical structure of the AEV to increase energy efficiency. The bracketing of the AEV was reduced to decrease weight and the code was optimized to increase coasting to reduce unnecessary energy usage. These changes were utilized in the final testing period. During the final test, the AEV ran the course as outlined by the MCR twice. For each run, the total energy, the time of completion, and energy to mass ratio was recorded. Additionally, the AEV was tested for completion during each necessary stop, such as at the gate and cargo areas. The first test was the best run, as it resulted in a total energy of 284 Joules with a total time of 1 minute and 6 seconds. The energy to mass ratio was determined to be 1182 J/Kg. That said, the AEV did not perform as expected and came up short at the gate and cargo areas. From the data, the team suggests that the current code of the AEV be revised slightly to provide greater operational consistency. As of now the AEV performs differently under different scenarios.

1

This drawback would need to be resolved before the team would feel confident enough to mass produce the AEV. That said, the physical structure of the AEV is sound, and does not need to be revised in any way.

Table of Contents

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

3

Experimental Methodology……………………………………………………………………………………………….

3

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

4

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

8

Conclusion and Recommendations…………………………………………………………………………………….

8

Appendix (Supplemental Info, Long Term Schedule, Solidworks Models)....……….……………...

10

2

Introduction The team was tasked with designing an alternative energy vehicle (AEV). The AEV design was required to meet operational requirements, design constraints, and have a minimized energy to mass ratio. While keeping these constraints in mind, the team had to design an AEV that was capable of traversing a monorail track and reaching a cargo loading station. From here, the AEV needed to return to the starting point with cargo in tow. Operationally, the AEV needed to complete this task with energy efficiency, and needed to be programmed so as to properly function under possible inconsistencies with the cargo or track. Due to low energy availability, the AEV had to be energy efficient. The purpose of this project was to not only teach technical engineering skills but to also instill concepts of project planning, design creation, and teamwork. After the team became familiar with the majority of the technical aspects surrounding the construction of the AEV, several performance tests were subsequently conducted. The first of these performance tests consisted of designing two AEV concepts. During this time, the Team constructed two distinct AEVs and tested them. The power efficiency was measured and the most efficient AEV was chosen to be used in future performance tests. The second performance test consisted of designing two sets of Arduino code. Again, the power efficiency was measured and the code that resulted in the most optimal use of power was chosen to be used in future tests. The last performance test was conducted with energy efficiency in mind. The structure of the final AEV design was tweaked to allow for a lighter structure. The code was also altered to allow for greater efficiency in motor usage. After the performance tests were conducted, the final AEV and code moved on to the final phase of testing. During this time, the final AEV concept and code was tested for completion of all the necessary tasks contained in the MCR. The time of completion and the energy to mass ratio was noted after completion for each of the two final tests. The information discussed herein contains the results from performance tests and the final testing period. The results include, system analyses, screening and scoring matrices, Arduino code, and AEV prototype drawings and models. Additionally, the problems that arose from both technical difficulties and team interactions will be discussed at length. Overall, this report summarizes all that was previously achieved throughout the past weeks of the AEV design process.

Experimental Methodology

3

As mentioned in the introduction, the first week of performance tests involved designing two distinct AEV prototypes. In Solidworks, pre-designed AEV parts were assembled to create two fully defined designs that would later be physically constructed and tested in a laboratory setting. Both models were tested for energy efficiency by running them using the same set of Arduino code on the monorail track. The MATLAB analysis tool was utilized to test their respective energy efficiencies. By observing the resulting plots of power vs time, the AEV design with the greatest observed energy efficiency was chosen to be used in future tests. Additionally, the best design was chosen in accordance with the greatest relative scores in the decision matrices. The second performance test involved creating and testing two distinct Arduino codes. These codes were designed to complete the mission at hand while using different formats, which will be discussed in detail in the results and discussion sections. Each code was written in the Arduino language using function calls, such as motorSpeed for varying speed or goToRelativePosition for determining position. The third performance test focused on making small variations to the Arduino code and the physical

structure of the AEV to increase the power output of the AEV with concomitant reduction in supplied

power. Furthermore, the strategy to complete the tasks as outlined by the MCR was updated and

refined during this week. Energy optimization was to be accomplished by slightly altering the power

settings in the arduino code, which would allow for additional coasting of the AEV. Additionally, the

structure of the AEV was altered to allow for a lighter body, thereby decreasing the amount of power

needed to move the AEV itself. By changing the aforementioned variables, the energy to mass ratio of

the AEV could be increased.

During the Final Testing Period, the final design of the AEV and its code was tested in accordance with

the mission at hand. The AEV completed this mission by following a series of steps. The first step

involved the AEV starting at a predetermined point and eventually stopping between two gate

sensors for seven seconds. The gate then opened and the AEV passed through to eventually arrive at

the cargo area, where it then stopped to pick up the designated cargo for five seconds. The AEV

proceeded to reverse and began its return trip. As before, it stopped at the gate for seven seconds.

The AEV went through the gate and arrived at the drop off region to deliver its cargo. The total time of

the run was noted in addition to the energy to mass ratio, which is given by equation 1. The AEV was

scored based on these two metrics as well as whether it completed each individual step in the

process.

Energy to Mass Ratio : nergy/Mass Ratio (J/g) Energy Output (J) / AEV Mass (g)E = (1)

Results During the first performance test, the team compared the two design concepts of the AEV. Previously, the team narrowed down four different AEV designs that were designed by each member individually. In the appendix, Tables 1A and 2A show the results from comparing these designs using decision matrices. From the four designs, the team chose Kyle’s design, as it scored the highest in both of the decision matrices. This design would later be used as the first concept design for further testing. This

4

first concept was of similar design to the reference AEV, with some weight saving modifications and streamlining. The second concept design the team created consisted of a lighter frame, with motors on each end providing a bidirectional pusher configuration in forward and reverse directions. This design decision was founded from previously gathered data regarding pusher and puller configurations (Appendix Figures 1A and 2A). This data depicts an aggregation of a larger set of sample data from multiple teams of engineers, in which puller and pusher motor configurations were utilized. From this data, it was determined that a pusher configuration favors a higher advance ratio while a puller configuration is more efficient at lower advance ratios. Thus, a pusher configuration best fit the needs of the AEV given the circumstances. The creative design concepts that were used earlier in the process during creative design were taken into consideration, but simplicity and practicality won in the end. Using the screening and scoring matrices (Appendix Tables 3A and 4A) the second concept design scored the highest in most categories. That said, the team chose to predominantly focus on two characteristics, cost and energy usage. The overall cost of the AEV depended mostly on the Arduino board, and therefore using fewer frame components in the body of the AEV would yield a reduction in cost. This proved to be the case for the second AEV design, which was $3 less than that of the first design. The second design showed significant power savings over the first as well. The relevant data and concept comparisons can be seen below. Models of concepts 1 and 2 can be seen below in figures 1 and 3 respectively with corresponding Power vs Time plots in figures 2 and 4.

Figure 1: Isometric View of Concept 1 Figure 2: Phase Diagram of Concept 1 Run

Table 1: Phase Breakdown of Performance Test 1 Run with Corresponding Code

Phase Arduino Code Relation Time interval (sec)

Phase 1 Accelerating 0-1

Phase 2 Constant speed 1-13

5

Phase 3 deccelerate 13-13 (instant)

Phase 4 Brake (drift) 13-30

Figure 3: Isometric View of Concept 2 Figure 4: Phase Diagram of Concept 2 Run

Table 3: Phase Breakdown of Concept 2 Run with Corresponding Code

Phase Arduino Code Relation Time interval (sec)

Phase 1 Accelerating 0-1

Phase 2 Constant speed 1-11

Phase 3 deccelerate 11-11 (instant)

Phase 4 Constant speed 11-21

Phase 4 Brake (drift) 21-40

There was indeed a significant difference between the power usage in figures 2 and 4, which was likely due to a variety of possibilities. The energy savings demonstrated here is believed to be due to the weight reduction from the first concept to the second. The cross sectional area of concept 2 was also reduced resulting in less drag, which also contributed to energy savings. Additionally, the data possibly suggests that the energy usage was reduced due to the propeller configuration in the second design concept.

6

Performance Test 2 (PT2) was structured similarly to Performance Test 1. In this case, two different code concepts were tested using similar methods. Unfortunately, time constraints limited the amount of testing that could be done, and setbacks forced the team to focus on simply designing and refining a code that would allow the AEV to complete the mission at hand. That being said, every coding decision the team made had energy efficiency at the forefront. From PT2 throughout the final testing however, two code concepts did emerge and the data shows (Figures 5 and 6) that the first code concept was more efficient, if only slightly. The main reason for energy conservation here was switching active reverse thrust braking for more coasting and passive friction braking.

Figure 5: Power as a Function of Time for Concept Code 1

Figure 6: Power as a Function of Time for Concept Code 1

Performance Test 3 (PT3) was to further optimize the AEV for energy efficiency. Optimization using the code was already explained above and was not the focus of this part, as the team was still just trying to get the AEV to perform the mission. However, some brackets and structural elements on the AEV were removed or simplified to conserve even more weight. It was during PT3 that a completed code was finally able to be tested, and the mission was finally able to be carried out by the AEV as it was intended. For the final test run, the AEV went smoothly to the gate, but needed to be adjusted by hand to allow the gate to open. From there, it went around the turn and picked up the cargo firmly, yet it did not crash into it. On the way back, the AEV did have to be adjusted again for the gate to open, and it finished by stopping in the correct location in the drop off region. The AEV waited for the exact amount of time in all phases or locations that it was called for. Unforeseen inconsistencies between runs detracted from what would have otherwise been a perfect performance by the AEV. This will be discussed along with other errors in the discussion section below. The data gathered throughout the two final tests is available in Table 4. Table 4 shows that the results between the two test runs were slightly different, particularly in the energy to mass ratio result with a difference of nearly 100 J/kg. Despite energy differences, the AEV ran for identical lengths of time for each test.

Table 4: Final Test Results

Final Tests 1 2

7

Total Time (mm:ss)

01:05 01:05

Total Energy (Joules)

284 303

Energy Mass Ratio (J/kg)

1188.62 1289.3

Discussion In theory, the AEV should stop at the same mark every run when using the absolute position commands. Throughout the entirety of performance tests and the final tests, there were discrepancies between runs that are still unable to be explained completely. Starting the AEV in the same spot on the same track would yield different results for distinct, successive runs. The varying results seen from each run emerged without the code or the AEV being adjusted. This may have been due to wheel slippage, with the sensor wheel either turning too much or not enough due to friction. Each run needed to be conducted three times in succession in order to deduce any necessary programming changes. Prior to the final test the AEV completed the mission perfectly twice without team member intervention and without any changes made to the code. These discrepancies in results would ultimately impact the mission at hand, as described in the MCR. There were several possible sources of error while testing the performance of the AEV, which could explain the aforementioned inconsistencies in its performance. One of such possible errors was track differences between the two rooms that were used for testing. These tracks were sufficiently different as to warrant a separate code being prepared for each, although this was a simple fix and did not impact energy consumption to a significant degree. Additionally, the team believes that the battery issued at the beginning of each lab period had an impact on the performance of the AEV. Since it could not be guaranteed that the same battery with the same level of charge was used for each test, a confounding variable was likely introduced. Varying levels of voltage may have had an impact on performance, and necessitated code adjustments at the beginning of each lab period, costing precious time. Another major error was that R2D2 fell off of the cargo mount several times and had to be glued back on. This extra glue added weight, and may have affected the center of gravity for the whole system. This could have also contributed to the needed for adjustments to the code. As for the final AEV design, all the acquired data indicated that it was superior to any previous design that was tested. The power consumption was of the AEV itself during test runs was less than that of concept design 1 (Figures 2 and 4). As suggested in the results, this was likely due to a reduced mass as well as the chosen motor configuration of the final AEV design. The results from previous experiments (Figures 1A and 2A) indicated that, in theory, the pusher motor configuration was most energy efficient. Comparing the results from PT1 does in fact show that this was the case. In addition to optimized power consumption, the final AEV design consisted of better scores in the decision matrices (Tables 1A through 4A) in all areas when compared to previous models. Finally, the reduced cross sectional area of the final design likely contributed to a reduced need for power, which is a

8

direct result of reduced drag. In conclusion, the final AEV design was in fact the most energy efficient and operationally consistent vehicle the team created.

Conclusion and Recommendation Lab 8 or Performance Test 1 was separated into 3 different parts throughout the week. Throughout lab 8, each design was tested, and the results were documented and compared. While conducting a pre-run, the lithium battery caught fire. After overcoming this setback, the testing process went smoothly. That said, some time was lost due to precautionary testing. As such, the group fell slightly behind in future performance tests. During the test of the first design, the AEV was unable to achieve forward motion. It was determined that a plastic lip at the beginning of the track was impeding the motion of the AEV, so extra power was added to the code in order to solve this problem. After the code was adjusted both designs were able to achieve forward motion and complete their code. The team learned that the second design was superior to the original design. It was discovered that the second design is lighter, more energy efficient, and more adaptable than the initial design. The position of both propellers in opposite direction of each other allowed the AEV to implement pusher configurations for both directions of movement. This configuration provided more thrusts and power to the AEV as compared to the installation of propellers with parallel thrust lines, as in concept design 1. During Performance Test 2, the team formed 2 separate codes that were distinct from each other in terms of the technical approach. The first code used a mixture of goToRelativePosition and goToAbsolutePosition function calls to operate the AEV. The first code also utilized drifting principle into the movement of the AEV along the track in order to reduce any unnecessary power consumption. The team also found that the reverse function is highly compatible with the AEV design as a decelerating mechanism. The second code used only the goToRelativePosition function to navigate the AEV. The second code was designed based on a systematic segregation of multiple parts of the track. This set of code also utilized the celerate function calls as a decelerating mechanism, which was used around turns to decrease the instability of the AEV. The first set of code was able to be edited with ease during future performance tests, as changing the structure of the AEV to improve energy efficiency would likely result in needed alterations to the Arduino code. As such, the team went forward with using the first code concept for future tests, as the adaptability of the code was key to completing tasks in a timely manner. Additionally, Figures 5 and 6 indicated that the first code concept was indeed more energy efficient. Having the entire team participate in coding allowed for greater overall understanding of the basic concepts, which would ultimately contribute to a higher quality AEV. Using absolute position function calls allowed for the editing of distances within the code with relative ease. Absolute position function calls allowed for the discernment of AEV distance along the track at all times. By using these function calls, the team was able make the AEV achieve a more consistent end location. This allowed the team to spend more time gathering data from the runs instead of spending time tweaking the code to get the AEV to end at the desired location. Lab 10 or Performance Test 3 focus mainly on the energy optimization of the AEV. Energy optimization was to be accomplished by slightly altering the power settings in the arduino code, which would allow for additional coasting of the AEV. Furthermore, the design of the AEV was changed to allow a lighter body mass to reduce the energy and power needed to generate the AEV. By changing its structure in this way, the AEV would need less power to move. Energy optimization was to be accomplished by slightly altering the power settings in the arduino code, which would allow for

9

additional coasting of the AEV. During the testing period, the group determined that the tracks in the two rooms were different from each other, therefore the same code was not used for both tracks. The group also discovered a possible reason that the result of our AEV is inconsistent is due to the fact that the batteries were affecting the the performance level of the AEV because of varying voltage levels. The group decided to continue implementing the reverse thrust and braking to consistently stop the AEV accurately. A recommendation would be to use the same battery for every lab to achieve optimum consistency. During Lab 11 or Final Testing the team successfully completed 2 full runs with the AEV. The score to the second final test was lower so the first test was used for the final score. During the scored final test the Vehicle failed to stop in the correct location to alert the gate sensor during the first leg of the track. The vehicle missed the mark by inches and required human intervention to correct the location. After the AEV moved through the gate, it perfectly landed to receive its cargo. During the journey back in nearly missed its mark to the gate sensor and required human intervention once more. The entire journey took 65 seconds. The total energy used during the successful trial was 284 joules. This makes the energy to mass ratio 1188.62 joules per kilogram. The AEV completed its mission, and finished the project with a respectable energy to mass ratio. What made our teams AEV design stand out was the low center of gravity, and inline oppositely facing propellers. The low center of gravity stabilized the AEV during movement along the rail, and the oppositely facing propellers made for efficient propelling, as well as braking. Throughout the project our group had major problems with the consistency of the vehicle from run to run. From run to run, the AEV ended in the different location, even when the design, code, and starting location remaining unchanged. As such, the operational inconsistencies were beyond the group’s control. These inconsistencies may originated from the battery, the arduino failing to correctly operate with the motors, or the motors themselves failing to draw consistent correct power from the battery. Also the problem could be stemming from the AEV itself being too flexible, and the wheels having too much tolerance. If this was the problem a potential solution could be found by the students, via 3D printing more rigid AEV parts, and wheels with tighter tolerances. However, without further testing, the true source of error was unable to be determined. Another future recommendation would be to find the source, or sources of the inconsistencies and attempt to solve the problem in greater detail.

10

Appendix

Figure 1A: 2510 Propeller in a Puller Configuration. Propulsion

Efficiency as a Function of Advance Ratio

Figure 2A: 2510 Propeller in a Pusher Configuration. Propulsion

Efficiency as a Function of Advance Ratio

11

Table 1A: Concept Screening Matrix for Initial Individual Designs

Table 2A: Concept Scoring Matrix for Initial Individual Designs

12

Table 3A: Concept Screening Matrix for Two Final Prototype AEV Designs

Table 4A: Concept Screening Matrix for Two Final Prototype AEV Designs

13

Semester Schedule Lab 1 Schedule

No. Task

Star

t Finish

Due

Date

Est

Time Kyle

Broo

k

Josh Vivian

%

Complet

e

1.

Setup the AEV

Software

30-

Aug

30-

Aug

6 -

Sept 1.20 0.20 0.20 0.20 0.20 100%

2.

Program the

basic function

calls controlling

the AEV

30-

Aug

30-

Aug

6 –

Sept 0.20 0.10 0.10 100%

3. Upload 30 30- 6 – 0.20 0.10 0.10 100%

14

Programs on

the Arduino

-Aug Aug Sept

4.

Learn

troubleshootin

g techniques

30-

Aug

30-

Aug

6 -

Sept 0.20 equal equal equal equal 100%

Lab 2 Schedule

No

. Task

Star

t

Finis

h

Due

Date

Est

Time Kyle Brook

Josh Vivian

%

Compl

ete

1.

Setup Reflectance

Sensor

6-Se

pt

6-Sep

t

13-

Sept 1.20 0.20 0.20

0.20

0.20 100%

2.

Load Sensor Function

Calls

6-Se

pt

6-Sep

t

13-

Sept 0.20

0.10

0.10 100%

3.

Troubleshoot

sensors

6-Se

pt

13-Se

pt

13-

Sept 0.20 0.10 0.10 100%

4.

Set up propulsion

system

6-Se

pt

6-Sep

t

13-

Sept 0.20 0.10

0.10

100%

5.

Test propulsion

system

6-Se

pt

6-Sep

t

13-

Sept 0.20 0.10 010 100%

6.

Link wind tunnel to

AEV

6-Se

pt

6-Sep

t

13-

Sept 0.20 0.10 0.10 100%

Lab 3 Schedule

No. Task Start Finish Due

Date

Est

Tim

e

Kyle Brook Josh Vivian %

Complete

Part A : System Analysis 2 : Performance Data Analysis

1. Downloading

EEPROM data

13 -

Sept

13 -

Sept

27

-Sept

1 1 100%

15

2. Convert

EEPROM data

to physical

parameter

13 -

Sept

13 -

Sept

27 -

Sept

2 1 1 100%

3. Calculate

performance

characteristic

using physical

parameter

13 -

Sept

13 -

Sept

27 -

Sept

1 1 100%

Part B : Design Analysis Tool

4. Upload wind

tunnel data

into design

analysis tool

13 -

Sept

13 –

Sept

27 -

Sept

2 1 1 100%

5. Upload

Arduino data

into design

analysis tool

13 –

Sept

13 -

Sept

27 –

Sept

3 1 1 1 100%

6. Conduct

performance

analysis of an

AEV operation

13 -

Sept

13 –

Sept

27 –

Sept

3 1 1 1 100%

7. Complete

progress

report

13 -

Sept

27 -

Sept

27 -

Sept

6.5 2 1.5 1.5 1.5 100%

Lab 4 Schedule

No. Task Start Finish Due

Date

Est

Time

Kyle Brook Josh Vivian %

Complete

1. Brainstorming

idea

individually

27 -

Sept

27-

Sept

4-

Oct

1.20 0.20 0.20 0.20 0.20 100%

16

2. Brainstorming

idea as a team

27-

Sept

27-

sept

4-

Oct

0.20 Equal

(in

class)

Equal

(in

class)

Equal

(in

class)

Equal

(in

class)

100%

3. Working on

construction

of the initial

AEV concept

design

27-

Sept

4 -Oct 4-

Oct

4 1 1 1 1 100%

Lab 5 Schedule

No. Task Start Finish Due

Date

Est

Time

Kyle Brook Josh Vivian %

Complete

Technique for design decision making

1. Formulate

Concept

Screening

Spreadsheet

4-

Oct

4- Oct 11-

Oct

2 1 1 100%

2. Formulate

Concept

Scoring

Matrix

Spreadsheet

4-

Oct

4- Oct 11-

Oct

2 1 1 100%

Testing the AEV

3. Program the

assembled

AEV

4-

Oct

4- Oct 11-

Oct

2 0.5 0.5 0.5 0.5 100%

4. Test the AEV

on track

4-Oc

t

4- Oct 11-

Oct

1.5 Equal

(in

class)

Equal

(in

class)

Equal

(in

class)

Equal

(in

class)

100%

5. Complete

Progress

Report

4-

Oct

11-

Oct

11-

Oct

4 1 1 1 1 100%+

Lab 7 Schedule

17

No. Task Start Finish Due

Date

Est

Time

Kyle Brook Josh Vivian %

Complete

1. Complete

Lab

Proficiency

Test

11-O

ct

11-

Oct

11-

Oct

1.20 Equal Equal Equal Equal 100%

2. Discuss Oral

Presentation

11-

Oct

11-

Oct

18-

Oct

1.00 Equal Equal Equal Equal 100%

3. Re-group

and ask

questions

11-

Oct

11

-Oct

18-

Oct

1 Equal Equal Equal Equal 100%

Lab 8 Schedule (Performance Test 1)

Task Start Finish Due

Date

Est

Time

Kyle Brook Josh Vivian %

Complete

Designing : 1st

Design

25-

Oct

25-

Oct

31-

Oct

1.20 0.20 0.20 0.20 0.20 100%

Designing : 2nd

Design

25-

Oct

25-

Oct

31-

Oct

1.20 0.20 0.20 0.20 0.20 100%

Test Run 26-

Oct

26-

Oct

31-

Oct

2 0.30 0.30 0.30 0.30 100%

Analyze Design

and Decision

Making

31-

Oct

31-

Oct

31

-Oct

2 0.30 0.30 0.30 0.30 100%

Lab 9 Schedule ( Performance Test 2)

Task Start Finish Due

Date

Est

Time

Kyle Brook Josh Vivian %

Complete

Arduino Codes 1

-Nov

1 -

Nov

8 - Oct

0.30 0.15 0.15 100%

18

Test : Speed 1 –

Nov

1- Nov 8 -

Nov

1.20 0.20 0.20 0.20 0.20 100%

Test : Balance

during turns

2 -

Nov

2 -

Nov

8 –

Nov

0.30 0.15 0.15 100%

Test : Brakes 2 -

Nov

2 -

Nov

8 –

Nov

0.30 0.15 0.15 100%

Test : Picking

up and

Delivering

7 -

Oct

7 -

Oct

8 –

Oct

0.30 equal equal equal equal 100%

Discussion :

Test Result

7

-Nov

7-

Nov

8 –

Nov

0.30 0.30 0.30 0.30 0.30 100%

Lab 10 Schedule ( Performance Test 3)

Task Start Finish Due

Date

Est

Time

Kyle Brook Josh Vivian %

Complete

Test 1 :

Track Run

14 -

Nov

15-

Nov

20-

Nov

1.00 0.15 0.15 0.15 0.15 100%

Test 2:

Energy

efficient

14-

Nov

16-

Nov

20-

Nov

1.20 0.20 0.20 0.20 0.20 100%

Test 3:

Consistency

15-

Nov

16-

Nov

20-

Nov

1 0.15 0.15 0.15 0.15 100%

Test 4:

Complete

track

16-

Nov

16-

Nov

20-

Nov

1 equal equal equal equal 100%

Lab 11 Schedule (Performance Test 4)

No. Task Start Finis

h

Due

Date

Est

Time

Kyle Brook Josh Vivian %

Complete

1. Run 1 :

Distance

21 -

Nov

21-

Nov

21-

Nov

2 1 1 100%

19

2. Run 1:

Time

21 -

Nov

21-

Nov

21-

Nov

2 1 1 100%

3. Run 1 :

Energy/Mass

Ratio

22 -

Nov

22 -

Nov

22 -

Nov

2 1 1 100%

4. Run 2 :

Distance

22

-Nov

22 -

Nov

22 -

Nov

1.5 1 1 1 100%

5. Run 2 :

Time

28

-Nov

28 -

Nov

28 -

Nov

2 1 1 100%

6. Run 2 :

Energy /

Mass Ratio

28 -

Nov

28 -

Nov

28-

Nov

2 1 1 100%

Arduino Codes: Concept 1: //Step 1: Begin in the drop off region, with front wheel just behind Mark 1. //———————————————————————————————————// //Step 2: Traverse to the gate region //Step 2a: Traverse main stretch of track (approximately 188.4 inches = 386.4578 marks) reverse(1); celerate(4,0,35,1); motorSpeed(4,32); //Run all motors at 25% power for goToAbsolutePosition(246); //Step 2b: Slow down AEV as it approaches gate sensor

20

brake(4); //Run all motors goToAbsolutePosition(433); //brake all motors for approximately 53 inches from current pos. reverse(2); motorSpeed(2,29); goFor(2); brake(4); goFor(7); //stay in current location for 7 seconds reverse(2); //———————————————————————————————————// //Step 3: Navigate to the cargo region //step 3a: exit initial gate area (4.25 inches = 8.7179 marks) celerate(4,0,35,1); motorSpeed(4,40); goToRelativePosition(142); brake(4); motorSpeed(2,20); //Step 3b: Traverse track to just before cargo pick-up region (231.40 inches = 13+2pi ft = 474.6667 marks) goToAbsolutePosition(958); reverse(2); motorSpeed(2,44.5); goFor(2); //Step 3c: Slow down AEV as it approaches cargo region (begin brake for 17inches prior to pick-up) brake(4); //Step 3d: pick up cargo and wait 5 seconds goFor(5); //———————————————————————————————————// //Step 4: Leave cargo region and proceed to gate //Step 4a: Reverse AEV and proceed to after the end of curved portion of track reverse(1); celerate(4,0,40,1); motorSpeed(4,45); goToRelativePosition(-231.7949); //Step 4b: Begin to slow down, and brake for 7 seconds after gate sensor brake(4); goToRelativePosition(-155); reverse(4); motorSpeed(4,22.5); goFor(2); brake(4); goFor(7); reverse(4); //Step 4c: After gate opens, proceed to after the end of second curved portion motorSpeed(4,45); goToAbsolutePosition(232); brake(4); //Step 4d: Brake AEV goToAbsolutePosition(115);

21

reverse(4); motorSpeed(4,42); goFor(2); brake(4); Concept 2: //Step 1: Begin in the drop off region, with front wheel just behind Mark 1. //———————————————————————————————————// //Step 2: Traverse to the gate region //Step 2a: Traverse straight stretch of the track (approximately 89 inches = 182.56 marks) celerate(4,0,30,1);// Extra push to give it a good start motorSpeed(4,25); //Run all motors at 25% power goToRelativePosition(182.56); //Step 2b: Reduce the speed of the AEV as it approaches the turn celerate (4,25,15,2) //Step 2c: Transverse across the turn of the track ( approximately 99.398 inches =203.893 marks) goToRelativePosition(203.893); //Step 2d : Proceed towards the cargo region (approximately 68 inches = 139.48 marks) celerate (4,20,5,2) goToRelativePosition(139.48) brake(4); goFor(7); //stay in current location for 7 seconds //———————————————————————————————————// //Step 3: Navigate through the gate region //step 3a: exit initial gate area (11.25 inches = 23.076 marks) celerate(4,0,30,1); //extra push to resume the speed motorSpeed(4,25); goToRelativePosition(23.076); //Step 3b: Traverse track to just before the turning region ( 60 inches = 123.076 marks) motorSpeed(4,25); goToRelativePosition(123.076); //Step 3C Reduce the speed of the AEV as it approaches the turn celerate (4,25,15,2); //Step 3d: Transverse across the turn of the track ( approximately 75.398 inches =154.663 marks) goToRelativePosition(154.663); //Step 3e : Prcoeed towards the cargo region (approximately 96 inches =196.923 marks) motorSpeed(25) goToRelativePosition( 196.923); //Step 3f: Slow down AEV as it approaches cargo region (begin brake for 24inches prior to pick-up) brake(4); goToRelativePosition(49.230); //Step 3g: pick up cargo and wait 5 seconds brake(4); goFor(5); //———————————————————————————————————// ////Step 4: Leave cargo region and proceed to gate

22

//Step 4a: Reverse AEV and proceed to after the end of curved portion of track(96 inches = 196.923 marks) reverse(4); motorSpeed(4,25); goToRelativePosition(-196.923); //Step 4b : Slows the AEV when approaching turn celerate (4,25,15,2) //Slows the AEV during turn //Step 4C: Transverse across the turn of the track ( approximately 75.398 inches =154.663 marks) goToRelativePosition(-154.663); //Step 4D: Proceed towards the gate (approximately 68 inches=139.487 marks) celerate (4 ,25 ,5,2); goToRelativePosition(-139.487); brake(4); goFor(7); //stay in current location for 7 seconds //———————————————————————————————————// //Step 5 : Leave gate region and proceed towards the drop off point //Step 5a: Proceed towards the turn (approximately 71.25 inches =146.153 marks) celerate(4,0,30,1);// Extra push to give it a good start motorSpeed(4,25); //Run all motors at 30% power goToRelativePosition(-146.153); //Step 5b: Reduce the speed of the AEV as it approaches the turn celerate (4,25,15,2) //Slows the AEV during turn //Step 5c: Transverse across the turn of the track ( approximately 75.398 inches =154.663 marks) goToRelativePosition(-154.663); //Step 5d: Traverse straight stretch of the track (approximately 96 inches = 196.92 marks) celerate(4,15,10 ,1);// goToRelativePosition(-196.92); //Step 5e : Slows down and break when reaching the drop-off point(approximately 17 inches = 34.871 marks) celerate(4,10,3,1); brake(4); Final Code Design: //Step 1: Begin in the drop off region, with front wheel just behind Mark 1. //———————————————————————————————————// //Step 2: Traverse to the gate region //Step 2a: Traverse main stretch of track (approximately 188.4 inches = 386.4578 marks) reverse(1); celerate(4,0,35,1); motorSpeed(4,34); //Run all motors at 25% power for goToAbsolutePosition(246); //Step 2b: Slow down AEV as it approaches gate sensor

23

brake(4); //Run all motors goToAbsolutePosition(433); //brake all motors for approximately 53 inches from current pos. reverse(2); motorSpeed(2,35); goFor(2); brake(4); goFor(7); //stay in current location for 7 seconds reverse(2); //———————————————————————————————————// //Step 3: Navigate to the cargo region //step 3a: exit initial gate area (4.25 inches = 8.7179 marks) celerate(4,0,35,1); motorSpeed(4,42); goToRelativePosition(142); brake(4); motorSpeed(2,20); //Step 3b: Traverse track to just before cargo pick-up region (231.40 inches = 13+2pi ft = 474.6667 marks) goToAbsolutePosition(958); reverse(2); motorSpeed(2,50); goFor(2); //Step 3c: Slow down AEV as it approaches cargo region (begin brake for 17inches prior to pick-up) brake(4); //Step 3d: pick up cargo and wait 5 seconds goFor(5); //———————————————————————————————————// //Step 4: Leave cargo region and proceed to gate //Step 4a: Reverse AEV and proceed to after the end of curved portion of track reverse(1); celerate(4,0,40,1); motorSpeed(4,47); goToRelativePosition(-231.7949); //Step 4b: Begin to slow down, and brake for 7 seconds after gate sensor brake(4); goToRelativePosition(-155); reverse(4); motorSpeed(4,21.5); goFor(2); brake(4); goFor(7); reverse(4); //Step 4c: After gate opens, proceed to after the end of second curved portion motorSpeed(4,47); goToAbsolutePosition(232); brake(4); //Step 4d: Brake AEV goToAbsolutePosition(115);

24

reverse(4); motorSpeed(4,42); goFor(2); brake(4);

25