u.osu.edu · web viewnext was concept screening and scoring, the third lab in which the team...

Critical Design Review

Submitted to:Inst. John Schrock

GTA Jin Yang

Created by:Group G

Elliott DehnbostelDaniel Keffer

Gabrielle RuheRachel Weber

Engineering 1182The Ohio State University

Columbus, OH4 December 2015

1

Executive SummaryIn the Advanced Energy Vehicle project, the team was tasked with designing an advanced energy vehicle (AEV) that was efficient, effective, and consistent in performance. The team used creative design techniques to collaborate and bring individual design concepts together into one final design. With their final design, the team was expected to produce an AEV capable of running solely on its own due to the programmed Arduino code uploaded to the Arduino via a USB cable. The AEV had to run on the track, stop at the first gate for eight seconds, continue on to pick up the R2D2, reverse and come back and stop at the second gate for 8 seconds, and finally, return back to the initial starting point. The team had fifteen weeks to come up with the best possible technique for the operation of the AEV.

At the beginning of the semester, the team spent time learning how to use the technology for analysis and production of the AEV. The team learned how to run a reflectance sensor test to make sure that the wheel counts were calculating AEV distance properly and how to program in arduino to give commands to the AEV. They learned how to use the AEV analysis tool, and they came up with several preliminary design ideas for the AEV. The team made design decisions quickly and efficiently using concept screening and scoring techniques to qualitatively rule out poor design decisions.The team spent the second part of the semester refining their preliminary ideas for an AEV to yield the best vehicle possible for final testing. The team went through a series of three performance tests where they used analysis tools to sufficiently determine which AEV design idea they would use for their final testing (performance test 4). With each performance test, their AEV was able to complete more of the tasks from the mission concept review, as well as perform more consistently.

While completing Performance Test One, the team was attempting to coast into the gate and rely on fiction to stop the AEV. While this was energy efficient, it was not consistent. This method was heavily dependant on battery power, which fluctuated depending on which battery the team was using and the charge left in the battery. The team was not able to complete an entire run using this method, but they used the AEV analysis tool and obtained that 85 J of energy were used to complete half of the track.

During Performance Test Two, the team planned to improve consistency with their AEV by getting a new battery to use every two runs. While this helped to improve consistency in their runs because the amount of power supplied to the motors remained relatively consistent, it became costly and inefficient. The team obtained data from this performance test of 186 J of energy. On the last day of performance test two, the team decided that the most effective way to perform the tasks at hand would be to implement a Servo arm into their design to brake the AEV when it reached the gate.

During Performance Test Three, the team spent the allotted lab time attempting to implement the Servo. They changed their Arduino code to provide more power than necessary, and then to brake with the servo once the AEV had reached a set absolute position right before the gate. They ran into multiple hardware issues. Initially, the Servo was not compatible with the arduino,

2

so the team replaced the arduino, Then, the team observed that the AEV was not calculating distance properly, so they ran a reflectance sensor test in each of their sensors. Each sensor was bad, so they replaced both sensors. The connection ports in the arduino seemed to not be recognizing some of the pieces of hardware that were connected, so the team replaced the entire arduino board. After replacing all of this, the team was able to have a working AEV. Due to all the hardware issues, the only analysis data that the team could collect was an assisted run with human interference using 152 J of energy. During the final performance test, the team’s AEV worked efficiently and consistently, yielding 224 J of energy usage and a weight of .27 kg, giving a mass to energy ratio of 823.08 Joules per Kilogram.

3

Table of Contents

Table of Contents ..……………………………….………………………………………………………………….………………..4Introduction …………...……………………………………………………………………………………………………..…...….…5Experimental Methodology ………………………………………………………………………………………..…...……..…6Results...………………………………………………………………………………………………………………………….….….…11Discussion …...………………………………………………………………………………………………………………..…........29Conclusion & Recommendations - Elliott Dehnbostel …………...……………………………………………....30Conclusion & Recommendations - Daniel Keffer …………………………………………………………..…….....31Conclusion & Recommendations - Gabrielle Ruhe …..…………………………………………………..……..…..32Conclusion & Recommendations - Rachel Weber …..…………………………………………………….…..….….33References ……………………………………………………………………………...……………………………………………….35Appendix ...………………………………………………………………………………….…………………………………..……..36

Introduction

The purpose of this project was to design an efficient and consistent AEV that would perform a series of tasks on a monorail. The team was tasked with several objectives that would all help them to meet the final goal of an independently operating vehicle. One objective that the team met was learning how to code in arduino. Additionally, the team learned how to use AEV

4

analysis software in collaboration with MATLAB and Arduino to analyze performance data and make design decisions. The team also learned how to troubleshoot both hardware and software issues and work together to reach solutions. This report will detail the fifteen week design process of the AEV. The team will discuss rationale behind design decisions the led to the final design. The team will also present performance test results and analysis that play played a key role in the design decision making. The team will then present and discuss final test results, as well as provide conclusions and future recommendations for the project.

Experimental Methodology

1. Task 1 - Creative Design ThinkingThe first lab completed, Creative Design Thinking, was an exercise in using creativity to draft several drawings of vehicle designs orthographically. The team drafted individual designs and a collective AEV design that they figured would best solve the problem posed (energy efficient,

5

aerodynamic, cost-effective). For this lab, the AEV desktop stand and the AEV kit were required. They were not used functionally but rather to aid in the team’s visualization of their AEV draft drawings. These drawings are figures 8, 9, 10, and 11.

Figure 1: Example Orthographic Drawing

2. Task 2 - Arduino Programming BasicsArduino Programming Basics was the second lab completed by the team. As the name suggests, this lab introduced the code that the Arduino would read and use to move the AEV. The team explored the syntax and behavior of the given functions and observed how they controlled the vehicle’s motors. The equipment required for this lab included the vehicle motor mount desktop stand, the AEV controller (in kit), the motors (in kit), USB cable for connecting the Arduino board to the computer and the Li-PO battery.

6

Figure 2 : Arduino Board and motor mount stand setup

Figure 3: Arduino Sketchbook AEV_Controller

3. Task 3 - Concept Screening and ScoringNext was Concept Screening and Scoring, the third lab in which the team completed. The team was introduced to concept screening matrices and scoring matrices--practical, concrete methods to compare multiple designs and score them based on user-defined criterion. Using this information, the team was tasked with comparing their drafts to a “base” design. The AEV

7

prototype was required to be assembled prior to lab time in order to perform this lab. The equipment needed in addition to perform this lab were the USB cable, the Li-PO battery and the desktop stand.

4. Task 4 - External SensorsThe team became familiar with the functionality and purpose of the external sensors on their AEV when they performed this lab. New Arduino functions were introduced that work in conjunction to the external sensors. In addition, the team was given information on how to troubleshoot their sensors in the case of error. The equipment required for the fourth lab included the assembled AEV, the external sensors, zip-ties provided by the lab instructor, the USB cable, the servo, the Li-PO battery and the desktop stand.

Figure 4: External Sensor on wheel (right) and Reflectance sensor (left)

Figure 5: Micro servo

5. Task 5 - System Analysis 1 - Propulsion EfficiencyThe following lab, System Analysis 1, focused primarily on wind tunnel testing. The team learned how to analyze the propulsion efficiency of their AEV draft and apply that information towards deciding what type of propeller system their vehicle would utilize. All of the equipment needed in order to complete this lab was provided by the instructor, as it was special testing equipment. Several wind tunnels were located at the front of the lab, with motors and propellers installed as either push or pull configuration and with different sized blades. The team was given a testing

8

sheet on Excel to fill out with the data fetched from the wind tunnel. The wind tunnel data can be found in figures 15 and 16.

Figure 6: Wind tunnel equipment

6. Task 6 - System Analysis 2 - Performance Data AnalysisThe sixth lab, Systems Analysis 2, introduced new data-analysis software and techniques to the team. EEPROM Arduino data provides physical results that tie to the team’s code and AEV performance and is integral to designing an efficient final vehicle model. The team used the EEPROM on the Arduino Nano to fetch raw data and made calculations based on that to receive their final data to analyze. The team’s assembled AEV, the USB cable and the Li-PO battery are the only pieces of equipment required to execute this lab.

7 .Task 7 - Design Analysis ToolFor this lab, the team was given another method of analyzing data via the MATLAB application named the Arduino Analysis Tool. Using sample data, the team explored the practical utilization of the app and how they could apply it towards improving their AEV model. As this lab was entirely completed on the computer with provided sample data, no physical equipment was required. Figures 17, 18, and 19 show the result of the design analysis tool.

8. Task 8 - Performance Test 1 - DesignThis lab was to be completed in three phases by the team in order to fully test the functionality of their vehicle and its code. The first performance test required the team to test two different designs, Design One and Design Two. Design One used both motors to pull the AEV while Design

9

Two only used one motor at a time. The vehicle was required to reach the gate, wait, and travel to the turn-around point. Equipment needed for this lab included the fully assembled AEV, the USB cord, and the AEV desktop stand. Figures 20, 21, and 22 show the performance comparison between the two designs.

Figure 7: AEV Track9. Performance Test 2 - Code

This lab was to be executed in three phases by the team in order to fully test the functionality of their vehicle and its code. The second performance test required the team to create two different versions of code that could complete the track. Equipment needed for this lab included the fully assembled AEV, the USB cord, and the AEV desktop stand. See Figures 21 and 22 for results on performance and energy usage.

10. Performance Test 3 - Energy OptimizationThis lab was to be executed in three phases by the team in order to fully test the functionality of their vehicle and its code. The third performance test required the team to modify their physical design and software in order to maximize energy efficiency. Equipment needed for this lab included the fully assembled AEV, the USB cord, and the AEV desktop stand. Figures 23, 24 and 25 show the performance and energy consumption of this performance test.

10

ResultsThe following drawings, graphs and tables have been compiled from each lab outlined above. They have been ordered sequentially and will be explained in a way that flows with the design process of the overall AEV project.

11

Figure 8: Gabby’s AEV concept

12

Figure 9: Elliott’s AEV concept

13

Figure 10: Rachel’s AEV concept

15

Figure 11: Daniel’s AEV concept

The team was initially tasked to design their own individual AEV prototypes. At this point in time, the team only had knowledge on the background and mission objective of the project as well as the AEV kit. Given this, each team member utilized their design abilities to create an orthographic concept sketch of their prototypes.

Table 1: Concept Scoring Matrix from Lab 3.

The group performed concept scoring for each individual AEV design. The group gave the AEV rating for each success criteria, and then multiplied the rating by the weight of importance of that success criteria. At the end, the scores of each individual success criteria were summed to come up with the total score. The total score of the reference AEV was 2.45. The scores of each of the AEV’s containing concept scores greater than each of the reference AEV continued on in the design process, and were used to design the group AEV (Figure 12). The AEVs that continued can be viewed in Figures 9, 10 and 11.

16

Table 2: Concept Screening Matrix from Lab 3.

Success Criteria

Reference

Group Elliot Daniel Gabby Rachel

Cost 0 - 0 0 - +

Aerodynamics

0 + 0 + 0 +

Environmental

0 0 0 0 - 0

Balance 0 + + + + 0

Weight 0 - 0 0 - +

Balance around turns

0 + 0 + + +

Aesthetic appearance

0 + + 0 - 0

Sum +'s 0 +4 +3 +3 +2 +4

Sum 0's 7 1 4 4 1 6

Sum -'s 0 -2 0 0 -4 0

17

Net Score 0 +2 +2 +3 -2 +1

Continue? YES YES YES NO YES

The group performed concept screening for each design. The group assigned a 0 if the AEV design being analyzed was better than the reference AEV in that particular success criteria, a minus sign if the AEV design was worse than the reference AEV, and a plus sign if the AEV was better than the reference design. At the end, the team added up the sum of “-”, “+”, and “0” to achieve the net scores. All net scores that were above zero (The net score of the reference AEV) were allowed to continue on in the design process, and were used to help make the group draft of the AEV (Figure 14). The design’s that continued are shown in Figures 9, 10, and 11.

18

Figure 12 : Combined AEV DesignFigure 14 is group’s original AEV design that combines Figures 9, 10, and 11 from Lab 1. This design was used for two different AEV concepts. Design Number One runs both motors at once, and Design Number Two runs one motor at a time.

19

Figure 13: Puller Propeller Thrust v. PowerFigure 15 is a chart plotting the thrust versus the percent power of the arduino for a puller style propeller. It shows that with an increase in power the thrust increases on an exponential curve. If thrust was the only desired result maximum power would be the most ideal setting. The puller propeller is ideal for max power situations.

Figure 14: Puller Propeller Propulsion Efficiency v. Advance Ratio

20

The figure above is a chart plotting the thrust versus the percent power of the arduino for a puller style propeller. It shows that with an increase in power the thrust increases on an exponential curve. If thrust was the only desired result, maximum power would be the most ideal setting. Therefore, puller propellers are ideal for max power situations.

Figure 15: Power Over Time (Lab 6)Breakdown of Figure 15 into phases can be observed in Table 3.

Table 3: Phases of Arduino Code

Phase one represents the celerate(4, 0, 30, 3) command, as it shows an increase in power draw over time. Phase 2 represents a constant power draw over time which is representative of a goToAbsolutePosition(130) command, and that command does not influence motor speed. Phase 3 represents the brake(4) command, as a lot of power must be drawn quickly to stop the motors quickly. Phase 4 represents the reverse(4), motorSpeed(4,30), and goFor(3) commands,

21

as motorSpeed(4, 30) instantly sets the motors to 30% power with no ramp up like celerate(4, 0, 30, 3). This means the motors will draw a constant power for 3 seconds. Phase 5 represents no power draw: the AEV is coasting. One thing that might change is getting rid of the need to reverse motors and instead coasting into the gate in order to save power.

Figure 16: Power Over TImeThis graph was created using the AEV analysis tool. Further explanation is provided after all the data from the AEV analysis is displayed in Table 4.

22

Figure 17: Power Over DistanceThis graph was created using the AEV analysis tool. Further explanation is provided after all the data from the AEV analysis is displayed in Table 4.

Table 4: Power Over Distance And Time

The two graphs created compare Power v. Distance and Power v. Time, a distinction that reveals insight on how certain functions in the AEV’s code use power. The graphs were created using the AEV analysis tool. As observed in the Power v. Time graph (Fig. B), the AEV increases its power input (Table 1) as it calls the celerate function (Fig. A). As the code performs the motorSpeed() function, the power input levels off relatively for 5.5 seconds before the AEV brakes and is cut off from all input power so it can coast.

Performance Test One

23

Figure 18: Power Over Time-- Power Vs. Time Compare Design One and TwoThis graph was created using the AEV analysis tool during performance test one. The blue line shows the power used over time for both motors running at once (lab 8a) and the red line shows the power over time for only one motor running at a time (lab 8b). The AEV design using less power over time was Design Two, making Design Two the most efficient.

24

Figure 19: Power Over Distance -- Power Vs. Distance Compare Design One and TwoThis graph was created using the AEV analysis tool during performance test one. The blue line shows the power used over distance for both motors running at once (lab 8a) and the red line shows the power over distance for only one motor running at a time (lab 8b). The AEV design using less power over distance was Design Two, making Design Two the most efficient.

Figure 20: Total Energy Used Design One vs. Design TwoThis table compares the total energy consumed by Design One versus Design Two. Design Two uses only 85.77 Joules while Design One uses 98.98 Joules. In the interest of best energy efficiency, Design Two was the design the team settled on continuing.

25

Table 5: Phase Table for Design One

This table shows the amount of energy that the respective lines of code used. Compared to Figure 20, Design Two used about 13 J more energy than Design One.

Table 6: Phase Table for Design Two

This table shows the amount of energy that the respective lines of code used. Compared to Figure 20, Design One used around 13 J less in energy to accomplish the same task.

Performance Test Two

26

Figure 21: Power v. Distance of Performance Test 2During Performance Test Two, the team attempted to replace the battery more frequently in order to create a more consistent AEV. This worked better than previously, when the team

hardly ever replaced the battery, but the team still was not satisfied because the AEV was still performing inconsistently.

Figure 22: Total Energy Used during Performance Test 2Before the improvements made to Design Two, this version of the team’s AEV consumed

roughly 187 Joules of energy during the total run.

27

Performance Test 3

Figure 23 - Power v. Distance Comparison of P. Test 3 First Run and P. Test 3 Second RunFigure 23 compares the amount of energy consumed by each design in relation to the distance the vehicle traveled. The design from performance test two has a spike of power consumption after the first motorSpeed() command as a result of powering the reverse motor to stop. This is

not present in the design from performance test three.

28

Figure 24 - Power v. Time Comparison of P. Test 3 First Run and P. Test 3 Second RunThe figure above compares the amount of energy consumed by each design in relation to the time spent running. The design from performance test two has a spike of power consumption after the first motorSpeed() command as a result of powering the reverse motor to stop. This is not present in the design from performance test three.

Figure 25 - Energy Consumption of P. Test 3 First Run v. P. Test 3 Second RunDesign 3 (servo implementation) consumed roughly 82% of the power that Design 2 used,

making the improved Design 3 more efficient.

29

Performance Test 4: Final Testing

Figure 26: Final Testing AnalysisThe third and final design (servo implementation) yielded a consistent and working AEV. This AEV used 224 J of energy. While this was higher than the previous tests, the AEV was able to complete the objectives independent of human help, and consistently with every run.

30

Discussion

In lab 8 the team designed two similar AEV’s that differed only by the direction of the propellers. In design 1 the propellers and motors were both mounted in the same direction using both motors in unison. In design 2 the team mounted the propellers in opposing positions using only one motor at a time.

These designs were created thru a creative design process. The team individually designed concepts for the aev design. These concepts were compared to each other and judged on their capability and design. The best design ideas were carried forward toward the final design. Lab 07 was used to gather data to make the best decision on the direction of the motors for the AEV.

With this design the team moved forward to the performance tests. The performance tests honed the teams programming skills and exposed deficiencies in the AEV’s design. The team originally attempted to brake the AEV with reverse thrust from the motors. This proved to be inefficient as well as inconsistent, as the battery was drained. With this information the team decided to implement a servo brake in place of the reverse thrust. The performance tests also revealed multiple hardware issues that were corrected before the final test. These issues included bad sensors, a malfunctioning arduino board and servo.

Once a set design was decided on, the team tallied the cost. the AEV was found to have a final cost of $181.32. This was $26.63 under the cost of the entire kit.

During the final test the AEV performed exactly as planned except it used more energy than usual and during the final length of the track it stopped early. The team surmised that on the final turn the AEV encountered excess friction than in previous runs. This prevented the AEV from reaching its normal speed and as the servo was enacted it stopped the AEV sooner due to less momentum. The team believes by moving the servo engagement point further down the track and using more consistent power this problem would be solved. Overall the AEV performed well scoring a 48 out of 50 points on the final test. With the only deductions coming from the short stop. The AEV had the fifth best energy to mass ratio at 823 j/kg. The AEV performed well in the final test but the team believes there is much more capable from this design.

31

Conclusion & Recommendations - Elliott Dehnbostel

Overall, this was an effective project. The team learned a lot throughout the process, including dealing with conflicting ideas and being able to create effective compromises to accomplish the mission goal.

The final design of the AEV included a few things that increased performance. The most noticeable feature is the servo brake that allows the AEV to stop very quickly. This did a couple thing for the team. The first and most important thing the servo does is make the AEV more consistent so that the battery does not have to be changed every few runs and the code can be kept the same. The servo is also more energy efficient than using the propellers to brake. Another physical feature of the AEV is the motors facing in opposing directions. This allows the AEV to be more efficient on both the forward and return trips. This is because if the motors are colinear and face in the same direction, and both are used at once, one motor buffets the other and decreases the other motor’s efficiency. On the return trip, the motors are working in an unintended direction and are therefore less efficient. The last physical feature of the AEV is the wheel placement. The wheels were pushed close together to make traveling around the turns smoother and prevent energy loss to becoming caught on a turn.

The overall function of the AEV was slower than the rest of the class, the the AEV was on the upper end f the class mass distribution, at 0.27 kilograms. The lowest mass AEV was 0.23 grams and the highest

AEV in the class. The primary reason so much energy was used is the motors spent a lot of energy and time on a bump in the track.

The primary way that the AEV could be improved is to make the final servo command happen slightly later so that the cargo fully reaches the end of the track, as the AEV did not reach the end of the track in the final test. Some improvements could be made to the commands that make the AEV move in order to cut down on energy consumption as well. These are things that may have been accomplished were there not as many hardware issues to deal with, but the team is content with what they achieved.

The most important result of this project is the knowledge of how following the engineering process of creating, testing, and improve can result in a much better end product than when not following the engineering process. The team also got a lot of practice with troubleshooting and finding where problems lie as a result of all the faulty hardware the team was given.

32

The AEV project could be improved by giving teams the opportunity to test their AEV outside of class. There were many points in time where the team felt as if a lot could be accomplished in having about an hour of time to work on the AEV. This is mostly due to the fact that, during class time, about half the time is spent waiting in line to test the AEV. The entire project would move faster and more efficiently if there is a way for teams to work outside of class.

Conclusion & Recommendations - Daniel Keffer

The Advanced Energy Vehicle design project is an engineering design challenge which the group collaborated to create an autonomous vehicle capable of completing a set of tasks. The group achieved this feat by utilizing the standard AEV kit as well as Arduino code programing and data analysis. The main task was to travel by rail to pick up a cargo trailer and return navigating a timed gate on both journeys while being as efficient as possible. Many factors had to be accessed to successfully complete this goal. These include the overall design of the AEV, the form of propulsion it would use, as well as the Arduino code. As the team progressed thru the labs many insightful techniques were used to analyze our data.

The teams AEV evolved over the course thru multiple iterations. The first design being one with both motors in line facing the same direction working in unison. The second design reversed one motors direction and used the motors interchangeably. The final design incorporated a servo brake to increase consistency and efficiency.

The teams AEV was focused on consistency first. Efficiency and speed were factors in the formulation of the code, but those goals would be useless if the AEV could not be able to traverse the track consistently and reliably. The code was designed to work whether the battery was half or fully charged. The team noticed many other teams coasting into the gate. This process undoubtedly saved them energy but made their AEV good for only one run. As the battery drained during the run their power levels would decrease. If they tried to run the AEV multiples times it would require changes to the code to complete the mission.

The AEV project was an enjoyable one but was not without its flaws. There was a heavy time constraint on the use of the test track. In an hour long session it was only possible to make a few runs as one had to wait in line. this was extremely detrimental to the writing of the code as its progress hinged on refinement thru multiple trials. this could be remedied by setting aside a test session outside of class or just reducing the size of the class. The second distinct problem in the AEV project was the unreliability of the Hardware. Malfunctioning hardware is a fact of engineering life but it becomes excessive when the main components of an AEV require replacement before the final test, as was our case. The troubleshooting of hardware should be

33

reduced to a minimum. Thoroughly test the electronic components before the kits are handed out would remedy this fault.

Conclusion & Recommendations - Gabrielle Ruhe

Over the course of the Advanced Energy Vehicle project, the team followed the sequence of labs and designed, tested and fine-tuned their personal vehicle model. The team was tasked for their AEV to not only to successfully travel along a track and pick up a cargo train but also to utilize energy efficiently. Creating an AEV that was energy efficient required a multi-faceted solution; propulsion, physical design and Arduino code all factored into the final efficiency of the vehicle. As the labs were completed, the team explored different methods of collecting and analyzing data such as the MATLAB AEV Analysis Tool. Learning how to correctly interpret results and apply changes to the AEV design based on that new knowledge was an integral component to ensuring the AEV would improve in performance and efficiency. Finally, the team was tasked with creating two versions of their vehicle prototype and comparing their performances. Design One ran both motors to move the vehicle while Design Two only ran one motor. Design Three introduced the servo to the team’s AEV, allowing the vehicle to brake more consistently and efficiently.

When compared to the class, the team’s AEV was shown to be slower and heavier, but it also proved to be one of the more efficient and reliably-performing vehicles. The mass of our AEV was .27 kilograms--as the class ranged from .23 to .29, the team’s AEV fell onto the heavier side. However, the energy mass ratio of the AEV’s final performance on the track was calculated to be 823.08 Joules per kilogram; the fifth most efficient AEV in the class. This could be attributed to the team’s decision to only utilize one motor in each direction. Since the motors never have to travel in reverse, the group’s AEV needed to consume much less energy to complete their run than other vehicles in the class required. Since the team’s AEV utilized the servo, it came to a stop using very little power; circumventing the issue of unreliable coasting to stop and high-energy consumption of using the brake function.

Multiple steps, upon retrospection, could be taken to have improved the team’s AEV performance. A lighter vehicle would reduce the energy mass ratio further, resulting in more ideal power consumption. Mounting the motors on smaller pieces or holding the arduino on a shorter base would lighten the mass of the team’s vehicle. Another improvement to the final vehicle model in order to decrease the energy mass ratio would be to streamline the code and fine-tune it more. The team ran out of time to really tweak their code to maximum efficiency while using the servo.

Overall, the AEV project stands for reasonable improvement in the future. A chief issue the team encountered over the course of the semester was a shortage of time with the test track.

34

Although it is unavoidable that more than one track had to be used due to changing rooms for lab and lecture, it made testing and preparing the team’s AEV for the final performance difficult because of the variations between the tracks. A proposed solution, in an ideal world, would be to allow the teams to pick a track to tailor their AEV to and solely test using that track. This would cut down on lost time the teams spend accounting for changing tracks. In addition, more extensive screening of the kits to assure that they contain working components would be another improvement. Hardware issues do happen and there is no avoiding that, but it is excessive to expect a team to replace almost all of their essential AEV hardware.

Conclusion & Recommendations - Rachel Weber

During the Advanced Energy Vehicle Project (AEV), the team was tasked with designing an AEV that would perform a series of tasks on a monorail. The main focus of the team was to design an AEV that could consistently perform in an efficient manner. Over the course of the design period, the team learned how to code in arduino, make design decisions using analysis tools, and collaborate as a team to troubleshoot and problem solve. The team was given fifteen weeks to complete the design process. In the first part of the project, the team spent time learning how to create the best AEV possible. The team learned how to use wind tunnel data and aev analysis data to make changes to their AEV design. The team also learned how to use concept screening and scoring matrixes to make design decisions. In the later part of the project, the team went through several performance tests in order to refine different iterations of their AEV-making each AEV design better than the one before. Over the course of performance testing, the team had main AEV designs. The first design ran both motors at the same time. The second design ran one motor at a time. The third design implemented a servo.

During the first performance test, the team used 85 J of energy. During this performance test, the team learned that it was more efficient running one propeller at a time rather than two propellers at a time. During this performance test, the team recognized that their AEV was inconsistent depending on battery power. During the second performance test, the team used 186 J of energy. The team attempted to replace the battery more frequently during this performance test in order to improve consistency. This solution still did not yield a consistency level that the team was satisfied with. The team decided that the best solution for improving AEV consistency would be implementing a servo. During the third performance test, the team used 152 J of energy. The team spend much of performance test three attempting to implement the Servo. The team had to replace the arduino and servo during this test. The arduino was not compatible with the servo, and the team spent much of the performance test troubleshooting how to fix the hardware. Prior to the team’s final test, the team replaced many pieces of the AEV hardware. They ran a sensor test and realized the sensors needed replaced. They also replaced both the arduino and arduino board.

Performance test four yielded relatively successful AEV. The team used 224 J of energy and weighed 0.27 kg, giving a mass to energy ratio of 823.08 J/kg. This was the fifth most efficient AEV in the entire class. Efficiency of the AEV was mostly attributed to the fact that the team ran

35

only one motor at once, rather than running both motors at the same time. The team’s AEV lost two points because it stopped too early before it got back to the final gate. This requires a simple fix of changing the absolute position that the AEV is commanded to go to by the Arduino. The AEV slightly heavier than some other AEV’s and therefore used more energy due to the implementation of the servo. The team believes that what their design gave up in terms of efficiency did not outweigh what their design gained in terms of consistency. Due to servo implementation, the team was able to design an AEV that performed consistently every time it ran due to the fact that it was independent of battery power.

In the future, the team would make improvements to their AEV by making lighter parts with the 3D printer. This would improve their energy to mass ratio. Additionally, the team would write the code so that the Servo arm does not snap quite as early as it did during the final testing. Future recommendation for future labs would be to have all of the hardware equipment tested before the labs so that each group has working hardware. Additionally, the group recommends adding in a performance test that would focus specifically on energy usage around the turns. This performance test would allow groups to analyze where they should cut the power around the curves in order to conserve energy.

36

References

1. Whitfield, Clifford, Dustin West, and Jacob Allenstein. The Ohio State University Advance Energy Vehicle Design: Lab Manual (2015). Web.2. “Technical Communication Guide: Fundamentals of Engineering 1181 & 1182.” Technical Translation (2006). The Ohio State University. Web.

Appendix

37

Table 7: Task Schedule

No. Task Finish Due Date

Daniel Elliot Gabby Rachel % Complete

1 Finialize AEV Design

Yes ASAP X X X X 100%

2 Solid Works Design

Yes 11/9 X X 100%

3 Working Code

Yes ASAP X X X X 100%

4 AEV Video Yes 11/17 X X X X 100%

5 Final Presentation

Yes 12/4 X X X X 100%

6 PDR Yes 11/9 X X X X 100%

7 Lab Memo 1 Yes 11/16 X X X X 100%

8 Lab Memo 2 Yes 11/23 X X X X 100%

9 CDR Yes 12/4 X X X X 100%

10 Project Notebook

Yes 12/4 X 100%

38

Figure 26: Design One Isometric SolidWorks Assembly

39

Figure 27: Design Two Isometric SolidWorks Assembly

40

PERFORMANCE TEST 1:

void myCode()

{

//accelerates all motors from 0 to 30% power in 3 seconds

celerate(4, 0, 30, 3);

//repeats previous function until AEV reaches the position of 90 marks from start position

goToAbsolutePosition(90);

//brakes all motors

brake(4);

//while total marks are not 171

while(!(getTotalMarks() > 171)){

//brakes all motors

brake(4);

}

//reverses all motors

reverse(4);

//sets all motors to constant 30% power

motorSpeed(4, 30);

//repeats previous function for 1.5 seconds

goFor(1.5);

//brakes all motors

brake(4);

//repeats previous function for 7 seconds

goFor(7);

//reverses all motors

reverse(4);

//sets all motors to constant 25% power

motorSpeed(4, 25);

42

//repeats previous function until AEV reaches position of 100 marks from its current relative

position

goToRelativePosition(100);

//code causing incorrect behavior commented out below

// brake(4);

// reverse(4);

// motorSpeed(4, 30);

// goFor(3);

}

PERFORMANCE TEST 2void myCode(){

//sets motor 1 to constant 35% power

motorSpeed(1, 35);

//repeats previous function until AEV reaches position of 90 marks from starting position


//brakes all motors

brake(4);

//repeats previous function until AEV reaches position of 181 marks from starting position



motorSpeed(2, 50);

//repeats previous function for .4 seconds

43

goFor(0.4);

//brakes all motors

brake(4);


goFor(9);


motorSpeed(1, 35);

//repeats previous function until AEV reaches position of 90 marks from current relative position


//brakes all motors

brake(4);


goFor(13);


motorSpeed(2,50);



//brakes all motors

44

brake(4);


goFor(9);


motorSpeed(2, 50);



PERFORMANCE TEST 3

motorSpeed(1, 30);

// goToAbsolutePosition(90); //90

// brake(4);

goToAbsolutePosition(210); // 190;

brake(4);

rotateServo(15);

goFor(9);

rotateServo(0);

motorSpeed(1, 35);

45


brake(4);

goFor(13);

motorSpeed(2,50);


brake(4);

goFor(11);

motorSpeed(2, 50);


PERFORMANCE TEST 4 motorSpeed(1, 35); goToAbsolutePosition(180); brake(4); goToAbsolutePosition(392); brake(4); rotateServo(15); //might need to be bigger goFor(3); rotateServo(0); goFor(6); motorSpeed(1, 33); goToRelativePosition(180); brake(4); goFor(13); motorSpeed(2,50); goToRelativePosition(-350); brake(4); goToRelativePosition(-15);

46

rotateServo(15); goFor(3); rotateServo(0); goFor(6); motorSpeed(2, 55); goToRelativePosition(-340); brake(4); goToRelativePosition(-30); rotateServo(15); goFor(2); rotateServo(0);

47

u.osu.edu · web viewnext was concept screening and scoring, the third lab in which the team...

Documents