Published using Google Docs
CDR AEV
Updated automatically every 5 minutes

AEV Critical Design Review

_____________________________________________________________________________________________________________________

 

 

Submitted to:

Inst. Barbara Wyslouzil  

GTA Hossein Qarib

 

Created by:

Group C

Brett Miller

Katy Hanson  

Tyler Weber

Joni Ford

 

 

Engineering 1182

The Ohio State University

Columbus, OH

26 March 2016

Executive Summary

Group C was assigned the task by the galactic empire to build a monorail system to prepare for war on the rebel alliance. Their Death Star was destroyed, and they need a cheap and energy efficient way to transport their R2D2 units. The galactic empire asked multiple teams of engineers to create an advanced energy vehicle to run on a monorail and to create a code using an Arduino microcontroller, designing it to complete this task. Group C includes members: Brett Miller, Tyler Weber, Joni Ford and Katy Hanson. The team’s goal was to create an AEV that uses the least amount of energy possible, but still transport the R2D2 units in a timely manner.

To complete the mission, each member created an initial design after conducting some research. Brett and Katy researched paper airplanes and their aerodynamics and designed AEVs using those concepts. Joni researched the modern airplane and its aerodynamics and used those concepts. Tyler’s goal was to minimize surface area of his AEV to reduce drag. They then created concept screening and scoring tables for the models and decided their final AEV model would resemble Joni’s. It would have a rounded base and its motors and wings would be centrally located.

In performance test 1, two designs were tested: one had a rectangular base and the other had the oval base as suggested. They were tested with the same code that brought each AEV to the initial gate. After running the energy analysis, it was noted that the AEV with the rounded base was more energy efficient, as the team hypothesized, and would be used for the remainder of the performance tests. During performance test 2, things became increasingly more complicated. The assigned task of this test was to find a code that would take the AEV to the initial gate, wait for seven seconds, pass through the gate, pick up the R2D2, wait for five seconds, travel backwards until the AEV reached the gate again, wait another seven seconds, pass through the gate, and travel back to the start. The group ran into many problems, especially with the sensors which counted the number of marks travelled. The group soon realized the sensors were counting the marks wrong. They tried multiple times to compute a mark to inch conversion, but could never get a consistent number. Also, the AEV would not count any marks backwards, so they had to use the “goFor()” function when bringing the R2D2 to the starting point. The team had to frequently utilized the guess and check method because of these problems. Because each performance test only consisted of three lab periods, group C had to use performance test 3 to continue to improve the code. One decision that was made during performance test 2 was that initially shooting the AEV at a high speed on the way there and back and then cutting the power and letting it coast to the gate/R2D2 was the most energy efficient route, which was the task of performance test 3. During test 3, the group finally made an almost perfect code and decided that they could use it in the final test.  

The group completed the mission because the R2D2 made it to the galactic empire; however, the group scored a 47/50 on the final test because as mentioned earlier the code was “almost” perfect. It is recommended that if this project is to be repeated, to run a sensor test before every lab period.

Table of Contents

Executive Summary………………………………………………………………………………………………………………….. 1  

Introduction……………………………………………………………………………………………………………………………… 3 

Experimental Methodology…………………………………………………………………………………………………… 3-6

Results………………………………………………………………………………………………………………………………… 6-14

Conclusion & Recommendations………………………………………………………………………………………. 14-15

Appendix…………………………………………………………………………………………………………………………… 16-32


Introduction

The AEV project was a semester long project that aimed at giving real world experience in the areas of team management, project design, and experimental analysis. The team developed an autonomous vehicle  that completed a specific task laid out before them.  The task at hand was to create a wind powered vehicle that could be programmed to autonomously travel on a monorail track. The vehicle would need to perform specific commands in order to complete the mission concept review and complete these tasks with the least amount of energy as possible. The goal was also to create this vehicle with the least amount of cost and to have a low energy usage to weight ratio.

The project background was that the rebel alliance has been forced to locate on a remote plant with a limited power source. The production plant that produces the R2D2 units used for the fighter crafts is located on the other side of the plant to keep it hidden. The rebel alliance is in need of an efficient transportation system to transport the R2D2 units from the production plant to the Hanger. The solution was the construction of an Advanced Energy Vehicle or AEV that could efficiently travel along an already built monorail to pick up and return the R2D2 units back to the hangers. This AEV was to be constructed to have a low energy usage to weight ratio in order to create a vehicle that would efficiently relay the cargo. Team C was tasked with designing this AEV to perform this task. The design process included the testing of initial code and vehicle design concepts with experimental data in lab as well as observations of trial and error test runs. Team C eventually completed an AEV that was able to complete the task set out in the Mission concept review. The AEV project methodology, data, and explanation of the final AEV project is outlined in this report.

Experimental Methodology

The AEV project process began with understanding the goal of the project and the task that needed to be completed by the AEV. The task was a complex task and involved the creation of an AEV that was able to  traverse forward on the monorail and perform various operations such as stopping, starting, and reversing direction to complete the task.

Figure 1: AEV monorail track

Figure 1  above shows the layout of the track for which the AEV traversed. Team C was assigned to test the AEV on the outer right side of the monorail track signified by the light green colored portion of the track in Figure 1. The AEV would start at the yellow dot located at half the length of the rectangular track and would travel to the green gate, stop there, travel to the other side to pick up the R2D2 unit, travel back to the green gate and stop, and then travel back through the gate to the starting point. The gate opened and closed based on two sensors located on both sides of the gate. These sensors were separated by about 7 inches of track on both ends of the gate. When the sensors were tripped they would open the gate allowing the AEV to travel through to the other side. The two sensors were set up as a fail safe system meaning that to open the gate the first sensor in the system of two needed to be tripped, but not the second sensor. If the second sensor was tripped then the gate would shut down and not open. Therefore the AEV needed to be coded to stop in the specified 7 inch window in front of the gate on both of its approaches to the gate.

The AEV contained an arduino microcontroller that stored the task code for the vehicle so it could operate autonomously (see Figure 2:  Appendix Tables and Figures). The code was used to control the AEV’s travel path in order to get the desired outcome on the track. The arduino microcontroller was connected to a lithium ion battery that supplied power to the AEV. The AEV also had track sensors that would be connected to the microcontrollers (see Figure 3: Appendix Tables and Figures). These sensors were attached to to the lever arm of the AEV where the wheels were attached. The wheels contained reflective panels that, with the sensors, would track the AEV’s position on the track. The sensors would count the number of times light was reflected off the reflective wheels as they spun as a basis for distance measurement. The arduino interpreted this value as “marks” and by finding out the circumference of the wheels used, the value was translated into inches. This made it possible to input a set amount of marks to move the AEV a measured distance on the track .

With the sensors and microcontroller, the AEV could be coded and controlled to perform distance and position specific task on the track. The team used the ability to track the AEV to set commands to initiate and terminate at specific positions on the track to refine the movement of the AEV. There was a specific syntax that was used for the arduino coding in prompting these commands. The basic functions for the AEV commands are outlined in Table 1 below.

Table 1: AEV Basic Command Functions

Arduino Syntax

Description

Example

celerate(m,p1,p2,dt);

Accelerate motor(s) “m” from power % “p1” to “p2” over time period “dt”

celerate(4,0,30,4);

Accelerates AEV from 0 to 30 % power over 4 seconds

motorSpeed(m,p);

Sets motor(s) “m” at speed “p”

motorSpeed(4,45);

Sets all motors at power 45%

goFor(dt);

Used to keep set a command’s operation for time “dt”

goFor(4);

Last command runs for 4 sec

brake(m);

Shuts off power to “m” motor(s)

brake(4);

Shuts off power

reverse(m);

Reverses polarity of motor(s) “m” . Reverses direction

reverse(4);

Reverses all motors

Once the task and how to code the AEV were understood, the Team began the design of the vehicle. Team C first brainstormed various design concepts and criteria that were important to allow the AEV to complete the task. These included, but were not limited to balance, weight, cost and wing design (see Table 2 & 3: Appendix Tables and Figures). From there each member of the team sketched initial designs for the AEV that they thought would perform the task in the most efficient manner as well as a final team design that the team came up with after looking at everyone's initial designs (see Figures 4-8 : Appendix Figures and Tables). These designs were drawn up as formal drawings with specific dimensions and in the three orthographic views. The designs produced by each group member were then evaluated based on the design concepts that were established by the team previously as important for the proper functioning of the AEV. A scoring matrix was used with weighted values on the concepts in order to determine which designs would be prototyped. The two designs that scored the highest value on the concept matrix were the ones to be created and tested on the track (see Table 3: Appendix Tables and Figures). Once two designs were chosen based on the group's initial evaluation, the designs needed to be empirically tested for if they were the most efficient and best designs possible. The designs were tested on the track and evaluated for their ability to travel on the track.

Some design components needed to be individually tested, and then incorporated into the the designs themselves. One of these was the wing/thrust configuration. There were two different wing/motor configurations the team could choose from, pull and push, and two different sizes of propellers, 2.5 and 3 inch diameters. The team used a wind tunnel and collected raw data to test the efficiency of these two wing configurations by evaluating the output thrust each gave with an input power. Using the raw data to find calculated values of efficiency, Team C decided on a specific setup and used this setup for both the AEV designs that were created earlier (see A1-A6: Appendix Equations).  

From this point on the labs focused on refining the prototype designs and the code for the best energy to weight ratio. The Arduino program had an AEV analysis tool that plotted the power consumption versus distance and time and gave the total energy usage in joules so that the test code could be evaluated for the energy usage. It used the raw data collected by the arduino during the run and the translation equations to automatically output the energy usage, time, current, voltage, and power values (see A7-A14 Appendix Equations). Every step from this point on used this tool and every decision made was based on the energy and power analysis given after each run. Using the energy analysis tool the team tested out the two designs that were made with the same generic code to see which one had the better energy usage and consistency on the track. This was tested many times to get a large enough set of sample trials to eliminate any outliers in the testing. A recurring issue was that the battery would randomly give more and less power to the AEV causing it to not complete the track properly. Many test trials were done before any major designs were chosen to try to minimize this randomization.  Once there was enough valid evidence to suppose one design was better than the other, that design was chosen over the other and made as the tentative final design. Small changes were made to this design as the test went on, but these changes were to fix problems that arose or damages that occurred to the AEV. They did not change the design expectations set out in the original design.

The next step in the process was to evaluate the code to produce the most energy efficient code. The team set up two general methods of coding or AEV travel so that each one could be tested against the other. The two methods were not specific code for the AEV, but rather how the team wanted to move the AEV. Team C’s methods were to either burst the AEV with initial power and let it coast or to slowly move the AEV along the track at a slow speed. Two sets of test code that utilized both methods of AEV coding were made. Each code successfully stopped the AEV at the gate window for the first approach to the gate. The energy was analyzed to see which one used less energy. Which ever one used less energy could be assumed to use less energy on the second half of the track since it would be the same method and same track. Once this method was established the detailed coding for the AEV was started. Within the method chosen, specific values for the power percentages to be used in the motors speed were tested for energy usage and run consistency. A few set of codes were created that successfully completed moving to and stopping at the gate in the first part of the track. Each code had different values for the motor speed and the energy was analyzed. Whichever one had less energy usage was used for the entire AEV code for all parts of the track.

The last part of the methodology for the AEV project was to refine and manipulate the code to make a code that programmed the AEV to successfully complete the task outlined in the Mission Concept Review. After the most efficient motor speed was found the team created a tentative code based on theory that would complete the entire task on the track. Team C then adjusted this code after many trial and error tests performed  in 4 rounds of performance testing of the AEV code. This was done until a code that consistently completed the task on the track was found.

Results & Discussion

Team C utilized trial and error testing, as well as data collected in lab, to make design and coding implementations to improve the AEV’s energy usage. For the AEV project, Team C began the design process with four prototype designs ideas created by each team member (see Figure 4-8: Appendix Tables and Figures). These designs and their concepts were incorporated into our two prototype design concepts that were used in the performance test. Each one was evaluated by the team under the set upon criterion established in the concept screening and scoring matrices (see Table 2 & 3: Appendix Tables and Figures). The team also made a team AEV design based on a group discussion in lab. The team design was created by analyzing the individual designs and incorporating the best qualities of each one. Prototype A below was one of the two  initial designs made out of the initial concept.  

image6.JPGimage8.jpg

       

         

Figure 11: Prototype A top view                                                 Figure 12: Prototype A right view                 

        

Prototype design A shown above in Figures 11 and 12 used the materials given in the initial AEV project kit (see Figure 25 :Appendix Tables and Figures). It closely resembled a standard airplane but without the curved ends. The base of the AEV was rectangular with trapezoidal shaped wings . The propellers were placed on the wings at the same level as base and in a pusher thrust mechanism just as a standard aircraft. The Arduino board was located in the middle of the base and the arm to the right of it with the wheels right above on the centerline of vertical symmetry and center of gravity. This gave good balance to the AEV on the track so it could fly without falling off, and so no energy was wasted in rotational motion. The power supply (battery) was placed under the AEV on a small platform that held it close to the base. Putting the battery under the Arduino allowed there to be more room on top of the AEV in case of the addition of any other components. This design manifested from aspects of all team member’s initial design concepts. Every team member based their design off the general mold of a current aircraft. The trapezoidal wings were present in most of the designs making it a part of the final prototypes designs. The second prototype resembles more of the actual team design, but could not be built and tested at the beginning due to the laser-cut base. This took time to make and this prototype was not ready to be made at the time of the design labs.  

image5.jpgimage4.jpg

       

Figure 13: Prototype B side view                          Figure 14: Prototype B top view

The second prototype design is shown above in Figures 13 and 14 (see Figure 26:Appendix Tables and Figures). This design kept many of the same general concepts of airplane design, but refined them making it more visually appealing and ultimately improved the weight to energy ratio. This second prototype design included the trapezoidal wings with propellers in a pusher thrust position just as prototype one. The base of the AEV was laser cut to have curved round edges at the two ends. This curved base design concept was formulated in the original creative design concepts  among the team. Its origin was found in Joni’s design sketch where she had a curved body as the base for the AEV.  Ultimately this design concept made it into the team design and this prototype design. The curved edges were expected to slice through the air much better than the orthogonal edges of the rectangular shape making the AEV more aerodynamic as it traveled on the monorail. This in turn will allow the AEV to use less power in performing the task at hand. Also, the removal of the excess material from the rectangular shape made the AEV weigh 7 grams less, which further maximized the energy to mass ratio. This weight being removed served no purpose and removing it aided in the overall effectiveness of the AEV’s energy efficiency. The curved edges also make the AEV look more like an aircraft than a flying brick making it more stylistic to the task at hand. The curved edges extend 5 dots backward from the front leaving three dots left in the middle where the wings were connected. This is so the wings could be attached without the loss of any holes for screws. There is an open flat dot at the front and the back of the AEV to allow for the magnet to pick up the cargo. There was one of these holes on both sides to maintain symmetry for aesthetic viewing. The support arm was moved to be more towards the right end of the AEV base because it added better balance. The original placement provided good balance, but the battery still had to be constantly shifted under the AEV to stop a slight tilt the AEV had when placed on the track. The arm was moved more on one side with the Arduino shifted slightly to the other. The battery was then attached to the support arm fixing this issue. The two designs were both based off the initial designs that made it through the initial concept scoring and screening and were changed slightly by the initial trial runs on the track.

The blade design was tested in lab with a wind tunnel to see what configuration would produce the best propulsion efficiency or most thrust with input power. The two design configurations to choose from we're a puller or a pusher configuration The puller configuration has the AEV blowing the air towards its body acting as a pull method to traveling (see Figure 9: Appendix Figures and Tables). The data collected from the wind tunnel testing  gave an overall propulsion efficiency. This was the ratio between the output thrust from the propeller to the input power in watts from the power source.  There were 12 data points taken as the power was increased to the blade configuration. The average propulsion efficiency (power input to thrust output) of the puller blade configuration was  2.94% with a max value of 6.88%. Figure 15 below shows the distribution between the Advanced propellor ratio and the propulsion efficiency.

Figure 15: System Efficiency vs. Advanced Propeller Ratio (Puller)

The puller configuration ended up having a very low average and max efficiency overall making it not a the efficient choice for wing configuration for the AEV. There would be a lot of power inputted into the AEv to get a minimal thrust return. This would hurt the energy to mass ratio because the energy would greatly increase while the weight would not making the ratio to large. The second blade configuration to consider was the pusher configuration (see Figure 10: Appendix Figures and Tables).  This resembled more of a traditional airplane design with the thrust line in the direction of travel but the air flow blowing in the opposing direction of body of the AEV as to provide direct thrust to the AEV as it moves on the track. Due to limited time in lab and many groups testing out blade configurations in the wind tunnel, Team C was only able to test the puller configurations propulsion efficiency. However the AEV lab manual gave a rough graph of what the pusher configurations propulsion efficiency would have looked liked. This graph is depicted below in Figure 16.

Figure 16: System Efficiency vs Advanced Ratio Pusher

Note: From Dr. Clifford Whitfield, The Ohio State Advanced Energy Vehicle Design Project Lab Manual, 2015

The pusher configuration would have had much higher average propulsion compared to the puller configuration. From the reference distribution Team C estimated that the pusher configuration’s average propulsion efficiency would have been close to 20%. This is around 15-17 % higher propulsion efficiency than the puller configuration. The pusher configuration would more efficiently transfer the input power into thrust making the AEV move farther with less power than the puller configuration. From these results prototypes A and B were both fitted with pusher configurations rather than puller.

Both prototypes were then evaluated in depth to decide which design would move forward in the testing process. The designs were re-evaluated by the concepts set out in the PDR concept screening and scoring matrices and by a test code and trial run to see which design used less energy with the same code (see Table 4 & 5: Appendix Tables and Figures).  For the aspect of balance on the track prototype B was better than A. Removal of the battery platform and attachment of it to the support arm rid the AEV of the battery’s weight in affecting the horizontal weight distribution since it was attached directly on the torque axis. The first design had issues with maintaining perfect balance and the battery had to be repositioned to fix the slight slant the AEV had on the track. Prototype B also has a better design style by being more compact, more aerodynamic looking and  having a red colored base.. Prototype B also concentrated the wires on the top and therefore were able to be clipped together keeping them of the way of the propellers. Wires hitting the propellers was a small issue with prototype Also the stretching of wires to reach the bottom for the battery connection port was also an issue in prototype A that was solved prototype B.  The center of gravity and the balance go hand in hand, and therefore B also scored higher in this category (see Table 4 & 5: Appendix Tables and Figures). Prototype A’s imbalance meant that the center of gravity was in a hard place to center all the materials at, making it a less effective design. Both designs had comparable maneuverability around the track making the designs equal in this category. The second prototype had a smaller size and was more compact which appeared to make it better in the maneuverability category, but there was no empirical evidence of this during test runs. Therefore the two designs were equal in this category.  In terms of durability, prototype A was more durable due to some issues with the strength of the laser cut plastic and some maintenance that was done on prototype B. This durability difference was not enough to make any serious consideration for design change, but in terms of absolute breakage, prototype A was more durable.

The cost factor was very important for determining the correct prototype. The cost of prototype A was $168.98 and the cost of prototype B was $155.46 (see Figure 27 & 28 : Appendix Tables and Figures). Prototype B cost $13.52 less than prototype A and therefore scored higher in the cost analysis. The Wing design was the exact same for both designs, with the use of a pusher method and trapezoidal wing shapes making this category equal. The last category was weight. Prototype B weighed less because it used less parts  (screws and small platforms), and had a lighter base. This made it overall weight 7 grams less than prototype A and gave prototype B  a better weight versus energy ratio. Prototype B ended up having a score of 4.025 while prototype A had a score of 3.675, meaning prototype B was being consideration  as the final design choice.

Prototypes A and B were then tested for their energy useage on the track as the final factor to consider before choosing the final design to move forward with. The prototypes were tested using a small section code to analysis the energy usage each design had.  This code was made into two variations to test two different ways to run the AEV. A 45 percent power burst for 2 seconds and a 35 percent power burst for 3 seconds was made and each prototype AEV was run with these codes (see Figure 17: Appendix Tables and Figures). Each code variation was coded to successfully begin at the starting line and travel up to and stop at the gate sensor. The AEV prototype that ended up having the better energy to weight ratio from the energy used in the test code was the one that would move on to the final testing phases of the project. Both prototypes used around the same amount of energy for the 35 burst code meaning no conclusion could be made about the which one was more energy efficient.

PT1 test 45 burst A andB.jpg

Figure 18: Performance Test 1 Prototype A and B “45 burst code” Power v distance

In the 45 percent burst test, prototype B used around 2 joules less energy than prototype A. This meant that prototype B was able to use less energy to accomplish the same task under the same code than prototype A. This made prototype B more energy efficient than prototype B. Overall Prototype B’s design had a lower energy usage with varying code, was lighter than prototype A by 7 grams and scored .35 higher on the scoring matrix. Also prototype B had a total estimated cost of $155.46 while prototype A had an estimated cost of $168.98. The conclusion team C came to based on the these results were that Prototype B would move forward as the final AEV design to be used in the Mission Concept Review.

The final AEV needed to be coded using the most energy efficient form of travel to reduce the energy usage. The team came up with two coding strategies or forms of travel that the AEV could take. The first method (Method 1) was to burst the AEV and let its own momentum coast it to the desired location either at the gate of the cargo. The second method was to slowly move the AEV along the track using a lower speed. The two methods were coded and tested for energy consumption on the first quarter of the track leading up to the gate.

PT3_spurt_distance.jpg

Figure 19: Method 1 energy usage on approach to gate

The power usage versus distance graph as a result of the first method of coding is shown in Figure 19 above. It employed a 45% initial burst for a brief time and then shut down power to the AEV allowing it to coast to the gate. The power usage for this run was 39.008 joules of energy, a fairly low amount of energy for the task performed.

PT3_memodata_distance [1043043].jpg

Figure 20: Method 2 energy usage on approach to gate

The second method used a 30 percent power thrust to control the AEV slowly all the way to the gate. Figure 20 above shows the power vs distance distribution for this test code trial. The power usage for this run was 56.743 joules. This meant that using the burst method with an initial 45% burst at the beginning was more energy efficient in accomplishing the task. Method 1 had a better weight to energy usage because it used 17.663 less joules of energy to accomplish the task over the same distance with the same AEV. The reason that the burst method (one) used less energy was because it utilized the momentum of the AEV. By bursting the AEV at the start, it gave the AEV an initial large velocity and momentum that carried it the rest of the track. Once an the AEV had this momentum, it moved under its own inertia and didn't need any energy for the rest of the motion as shown by the short time period of energy usage in figure #. The only forces working against the AEV’s momentum once in motion were the air drag and the wheel friction on the track both of which were small in magnitude allowing the AEV to coast a fair amount of distance on the track. In Method 2 the AEV wasn't going at a high enough speed to gain momentum to coast it meaning that there had to be a consistent power thrust to move the AEV. the power thrust was significantly lower than the coasting method but the AEV was moving very slowly on the track meaning there was more power usage over a longer period of time. The greater power burst at the beginning of the coasting method ended up being less energy usage than the lower steady use of energy in the second method. The main reason for this was that it is harder to force an object that is stationary into motion than an object that is in motion. The coefficient of static friction of the wheels and the motionless state of the AEV at the beginning meant that there needed to be more force, and by extension, more energy used to initially put the AEV in motion. Once the AEV was in motion this energy is significantly reduced to keep it in motion but initially the AEV’s inertia makes it want to stay motionless. Therefore the coasting method (Method 1) provides a large quick burst that breaks the threshold of energy needed to initially move the AEV at the very beginning allowing there to be less power usage to move the AEV for the rest of the code. The second method however did not break the threshold of motion immediately and slowly broke which caused more power to be used in the beginning stages of the AEV’s travel. This is where method 2 used more energy than method one. If the task allowed the AEV to always be in motion, then method 2 may have used less energy due to the lower initially spike in energy and the high power percentage. But the AEV must stop at many point in the task making method 1 the coding coding method with the lower energy use.

The team evaluated and decided to use the second coding method in moving forward with the AEV project mainly due to its significantly lower energy usage. There were advantages to method 2 the main one being that it was more consistent in controlling the AEV on the track. The coastin method would sometimes cause the AEV to overshot or undershot the target area on the track. This was because it was hard to judge how far the AEV’s momentum would coast it for each run and the battery would randomly give slightly different amounts of power to the motors without changing the power percentage in the code. This was due to the the physics of a battery and how the current and voltage pulled could vary slightly from run to run. It therefore made it very hard to consistently get the AEV to stay in the 7 inch target window in front of the gate. Method 2 was better at this because the AEV was moving a slower speed where the differing power amounts would be negligible affecting the speed of the AEV and when the motors shut off the AEV wouldn't have enough momentum to coast would coast very little if not at all. Overall though the team decided that the benefit in energy consumption from method one versus method 2 weighed the inconsistency.

Code was created for the AEV to finish the entire tak outline in the MCR. This code was created based on mathematical calculations of marks and inferred amounts of time for the AEV to run at 45 percent burst power. The code was put through many trial and error turn on the track in order to find the the right code that completed the task. Values for marks and time were changed based on many trial runs of the code in order to find the best average code that worked for the most amount of times and  for any battery given. The team was able to complete a tentative code for the AEV that successfully complete the entire task before the final run (see Figure 21: Appendix Tables and Figures). Figure 22 below shows the power versus time distribution for the entire run.

PT4_time.jpg

   

Figure 22: AEV Successful MCR Run Power vs Time PT4

The energy consumption was very low and the code only included 5 main power phases. These power phases were all short burst of power for a limited amount of time as shown by the 5 main peaks in the power distribution. The enrergy socnumsed for the phases varied slightly but was around 47.91 joules of energy. The exception was phase 2 designated by the small peak right after the large phase one peak. This was the reverse command use to slow the coasting of the AEV to the gate on its initial approach. This phase was very important because it greatly improved the consistency of the AEV reaching and not over or undershooting the sensors on its first approach to the gate. This phases used 2.244 joules of energy and lasted for only .93 seconds of time. Phase one and Phase 3 had lower energy usage than the Phase 4 and 5 because during phases 4 and 5 the AEv was pulling the R2D2 backwards on the track. Their energy was around 10 joules higher than the AEV’s by itself on its initial approach. The total energy of 197.018 was reasonable considering that the AEV weighed 247 grams. This gave a joule per gram ratio of .798 which is a very low amount of joules per gram considering the small size of a joule.

The cost of final AEV was relatively low for how energy efficient the team was able to make it. Team C was able to reduce this cost through the design process and trial and error testing during the performance test. The original prototype made from the AEV kit had a cost of $168.98 without any outside materials. It used a lot of screws, platforms and large pieces that were unnecessary that drove up cost and weight. Prototype B was created and eliminated the base and extra platform cost by using a lighter, smaller and cheaper base out of laser cut plastic. This cut the cost by  $3.00 and made the AEV more compact. By compacting the AEV with a custom measured base, a lot of the pieces used to extend the wings to give room for the propellers were eliminated. All the extra screws, plates and nuts used to stabilize the battery under the AEV and the flat brackets extending the motors out from the base on the wing were eliminated with the use of the compact laser cut base and placement of the battery on the lever arm. This eliminated a net $10.52 making the final AEV after testing cost 13.52 dollars less than the initial concept.

There were many instances of potential error throughout the lab. The project in general has many variables that go into the performance of the AEV on every single run, such as the level of the battery, the room the runs are done in, and other little variables that can have even the slightest impact on the runs. Sometimes, the propellor would come loose from the axle and fly off, making a faulty run. The battery would sometimes be at full charge and overshoot the gate, and would sometimes be at a low charge and undershoot the gate. The track in room 224 is longer than the track in room 308, which is another source of error in the coding of the AEV due to the specific marks and times used to move the AEV consistently and fluently run to run. These variables, some fixable and some not, are what cause the error from run to run and day to day in the AEV project.

Performance Test 1 confirmed the use of a base that is laser cut into an oval shape. When we did runs of the rectangular base vs the oval base, the oval base AEV used less energy, and was faster and lighter than the rectangular base, which is why it confirmed that the default rectangular base wasn't going to be used any longer. It also confirmed that the lower the weight of our AEV, and the better balance the AEV had on the track, the better the run would turn out, efficiency and time wise. The battery’s placement on the AEV was the most critical part of the balance of the AEV, because the battery is the part with the most weight on the AEV bedsides the Arduino, which was balanced in the center of the base, and once the perfect spot on the side of the arm was found, the balance was never a problem again. Overall, performance test 1 led to the final design of the AEV which was used throughout the entire rest of the project, which turned out to be a great design for the efficiency of the AEV in the end.

The AEV was tested twice for the Final Mission Concept Review. The first test run was only partially successful. The AEV was able to travel to the first gate, stop before the gate, travel through the gate and approach the loading zone. However, the AEV did not properly connect to the R2D2. The AEV pushed into the R2D2 with excessive force causing the AEV and R2D2 to bounce off of the pad positioned at the loading dock, which placed the AEV at a longer distance from the loading dock. The code then miscalculated the time to travel to the gate causing it to trigger the second sensor in front of the gate.. From there the AEV had to be manually traversed through the rest of the run.

The second run was much more successful, although not perfect. Upon approaching the gate to the loading dock, the AEV overshot the first sensor, and therefore had to be manually stopped before triggering the second sensor and disabling the gate. The AEV ran successfully until the very end of the run, when it stopped short of the starting point. The final analysis was therefore based on run 2. The Final Mission Concept Review AEV run performed with less energy than previous successful runs performed in the performance test. The run power versus time graph was fairly identical to the performance test 4 distribution with the slight difference of having 11 less joules of energy used.The final total energy used was 186 Joules which amounted the energy to mass ratio to be 753 joules per kilogram.

Conclusion & Recommendations

The AEV Design project was a project that lasted the whole semester, where each meeting in class was to build off of the previous week and make changes and improvements based on the energy use, cost, and overall efficiency of the AEV. The AEV was to move forward, stop at a gate for a certain time, move on once the gate lowered, pick up an R2D2 unit with a magnet, stop at the gate once again, and return to the starting point. The groups were to come up with their own design for the AEV and a unique code that completes the run effectively. The groups were to try to limit the weight, cost, and energy use of the AEV, which can be done using many different methods. There were many options and ways to go about completing the project, as the labs were open ended and loose, letting the groups decide how they wanted to use their time

Group C decided to use concepts and ideas from everyone’s individual designs in the final design. The base was to be laser cut into an oval like shape, to make the design more aerodynamic than the rectangular base. Overall, group C tried to limit the weight of the design as much as possible by not using many of the given parts on the AEV. There was a base, an arm, the arduino, wings, propellers, and a battery, which limited the weight to just 247 grams. Basically, the group tried to prioritize both weight and energy use, but focus more on weight for the design and energy use on the code. For the code of the AEV run, Group C decided to go with an initial burst of energy to really get the AEV moving, then cut the motors and let the AEV coast the rest of the way to the gate. A little reverse function was put in to account for any error in the battery as to not overshoot the gate. This proved to be by far the best method when it comes to efficiency, as the energy used was much lower using the burst method with coasting rather than keeping the motors running slowly the whole run. Group C used the reflectance sensors to count marks for how long to run the motor for the first part of the run, and after the R2D2 unit was picked up, the goFor command was exclusively used. This method of code proved to be very effective and as consistent as possible, while using very little energy. So, the use of the laser cut base along with 2 wings, evenly spaced propellers, and the burst coding method limited the energy use of the AEV, made the efficiency of the AEV very high, and overall worked very well for this design project.

There were many errors that came about during the semester long AEV design project, due to the many variables associated with the construction of the AEV and the use of many different pieces and parts during the project. The first error that occurred throughout the entirety of the lab was the inconsistency of the battery. Run to run, the battery would decide to sometimes have a lot of power and sometimes would give off very little power. Also, day to day the different batteries given out would be at different charges and levels of power, which would greatly affect the AEV’s runs. Although there was no perfect fix for this error, Group C did the best it could to change the marks and times in the code daily to account for the new battery. Also, the code was perfected as much as possible to work even if the battery were to overshoot or undershoot. Another error was that the arduino would frequently run backward when we would tell it to run forward, and vice versa. To fix this, a reverse command was put at the beginning of our code at first, then the group flipped the reflectance sensors to account for the error.

Group C would recommend using the burst code method in the coding of the AEV’s run. Compared to the rest of the class, Group C had the best efficiency of power used due to this method. It had such a good efficiency because of the use of coasting, which is movement that uses no energy from the motor. The use of a lot of energy to get it going is made up for by the coasting portion where literally no energy is used. Many other groups had the motors running the whole run, which uses a lot of energy and isn't very efficient. Group C would also recommend using a laser cut pieces in the Design of the AEV to make the design more aerodynamic. Many groups were using the original square base and other parts that just aren't very aerodynamically sound, and are very square, which increases drag on the AEV, which in the end lowers efficiency.

Possible improvements to the whole AEV project would be to get more consistent batteries. The battery being spotty was the most annoying part of the lab, because Group C would have perfected the code one day, then used the same code the next day in the same room and the AEV would come up well short because the battery wasn't as strong as the day before. This would make the code much easier to perfect and would make the lab more consistent. Another improvement to the project would be to allow more freedom with the direction of the project. There should be a little structure in the beginning of the project to get students started, but the students should be allowed to go wherever they want after that, and not waste days on things such as the wind tunnel test. It would be more beneficial to the groups if they could just try to spend most of the project perfecting the design and comparing designs and codes to each other, rather than worrying about little “side projects” that aren't as important to the final goal.

One reason for incompleteness is again, the battery was incredibly unpredictable. This makes it impossible to be complete in this project, because the battery would have to give off the same amount of energy every run for the code and project to be completely perfected. Also, Group C considered putting a rod-like structure that would swing up with the servo arm, and would hit the green block by the gate in case the inconsistent battery were to overshoot the window that had to be hit for the gate. However, the idea came about too late, and the group had spent the time up to that point dealing with faulty reflectance sensors that would triple count the marks, so the group didn't have time to implement this idea. This would have fixed the overshooting at the gate due to a bad battery for good, but time just didn't allow it. Overall, if more time was given to come up with ideas and test different methods and designs of the AEV rather than spending some labs on other side assignments, time wouldn't have limited the potential of Group C’s AEV.