Executive Summary
The AEV design project was completed to so that an AEV travels across a monorail track to pick up R2-D2 on a caboose, then travel in the reverse direction along the same monorail back to the original position. The goal of this is to create a design that is energy efficient, due to limited power on the remote planet, but also to create an aesthetically pleasing design. Other goals of the project included developing team-working, design, manufacturing, and brainstorming skills. The team set out by testing different designs and determined which ones should be tested further.
The first task presented was to copy the given sample AEV design so that team members could could become familiar with the coding for the Arduino. This design was then tested on the monorail system so the group understood where the AEV should stop. Due to malfunctions in the code and Arduino, the team was unsuccessful at putting the AEV on the track. The efficiency of different propeller designs was also tested using a wind tunnel. A 2510 pusher, 2510 puller, 3030 pusher, and 3030 puller were all tested, and it was determined that the 2510 pusher configuration provided the most thrust at certain power inputs; however, in testing in the lab, the group concluded that the 3030 pusher was more efficient and was going to be used in further testing.
The next task was to have each group member create their own AEV design, with the goal of achieving more power efficiency than the sample AEV. After the individual designs were made, the entire group collaborated to make a collective design. The collective design was the most efficient one made, so the group elected to continue with testing and altering that design. The initial group design was to add wings to the side of the main base of the AEV, which would provide more aerodynamic efficiency and would be aesthetically pleasing.
The next task was to use the design analysis tool from MATLAB so that the group could gain an understanding of how power was being used in different phases of the run, such as starting, traveling at constant speed, decelerating, accelerating, and stopping. The group would use this to collect data from the arduino controller to determine if the design needed to be altered due to problems in the design not being efficient enough. A concept screening and scoring table was made to compare all of the designs against different criteria, such as: balance, durability, cost, efficiency, and aesthetics.
The group then moved into performance tests, which focused on designs, code, and energy. The team is currently in the process of these performance tests in hopes that the final design and code will follow the objectives and goals mentioned above.
The AEV is needed for transportation of cargo across a remote planet by way of a monorail. Since the base is on a remote planet, energy is scarce and needs to be used efficiently whenever it is used, which means the AEV design that will be used will use as little energy as possible during its runs. Another problem with the remote planet is that the monorail will not always be the same length due to shifting faults, so the AEV design will need to be able to account for different distances and must have code that is easy and quick to alter.
Introduction
The purpose of these labs was to test AEV designs and continue to establish plans to improve the overall AEV Design. Through these tests, the team compared two major designs for the AEV to understand the practicality and efficiency of the two. Another part of these labs was the code that the arduino will run. The code that will be used must be a tested product and meet certain criteria such as stopping at the right times and performing properly in general. The purpose of this lab report is to inform the reader of the current baseline that the team has established
Experimental Methodology
Throughout the 10 weeks of the AEV project, there have been many different labs and procedures that have been addressed by the group. The first lab involved the group becoming familiar with the Arduino interface, while using various arduino methods to code a sequence of actions for the two propellers to follow. In this experiment, the group worked with Arduino Software, a sketchbook found on the class’s Carmen page, two propellers and fans for those propellers, a stand to hold the propellers, and Arduino Nano microcontroller, and a USB cable, and a battery The fans were put on properly to the propellers, and then the propellers were attached to the propeller holder. From here the group connected the Arduino Nano to both fans and the battery. Then two sets of code were made in order to test how well the group could use Arduino methods. Then a USB cable was used to upload both sets of code, one at a time, from computer to the Arduino itself. Both programs that were made worked as intended.
Lab 02A consisted of two major components. The first was working with the reflectance sensors. The group was tasked with setting up two external sensors on the model AEV, which it had constructed prior to class using parts in the AEV kit it received in week 1. After installing the sensors, the group was instructed to test the reflectance sensors using a method for the OSU Arduino Sketchbook called refletanceSensorTest(), along with troubleshooting any errors that could have arisen during testing. After this testing, the group made another program that would utilize new methods that required the reflectance sensors in order to work. These methods, such as goToAbsolutePostion, were used to test the functionality of the reflectance sensors, as well as give the group valuable experience with these new methods. Lab 02B involved testing two different propeller types and positions in a wind tunnel to see which propeller type is best to use for the team’s AEV and which configuration the team may want to use. The two positions tested included the ‘pusher’ configuration, which placed the propellers at the back end and the ‘puller’ configuration, which placed the propellers at the front end of the wind tunnel. The voltage was set to 7.4V in this experiment and the power generated, current and thrust scale were all read and recorded. The data recorded was then used to calculate calibrated thrust, power input, power output, propulsion efficiency and propeller advanced ratio. A graph of the propulsion efficiency and advanced ratio was then constructed to determine what propeller gave the team the most efficient results while still providing enough power to push the AEV.
In lab 03, the team brainstormed different ideas to come up with a design that the team would use moving forward. Each individual team member was to use orthographic paper and sketch a top, front and right side view of their design with proper dimensioning and come up with a design that would meet the criteria required as per the Mission Concept Review. The goal of this lab was to think of an AEV design that would be aesthetically pleasing, require a low power input (energy usage), and be able to balance on the track and complete the mission of bringing the R2D2 back to the starting point within the required timeframe (2 minutes and 30 seconds), while stopping at the gate for the required amount of time (7 seconds going forward and back).
Lab 04 was a little more complex; the first part involved a performance analysis of the team’s newly constructed AEV design after the brainstorming and building session of Lab 03. This lab involved coding and uploading into the Arduino program that would move the AEV to the first stop (just before the gate) and get the data from the test run and upload it onto MATLAB to record the time, current, voltage, distance, and position moved according to the measurements taken by the Arduino. This data was then converted into physical, measurable parameters using the formulas provided in the lab manual. The group also used MATLAB to construct a graph of power supplied vs. time and power supplied vs. distance. This graph was then divided into different phases to perform a performance analysis where the incremental energy of each phase was calculated to see where the team may need to improve overall code. The second part of the lab also involved the same procedure using a different approach, but with the same overall results.
For Lab 05, the main task was to do a sample run for one of the AEV designs and then to use that as a reference in the creation of a Concept Screening and Scoring tables. This lab included testing of the AEV on the track and for the team to come to a consensus on the aspects of the AEV that will be emphasised in the final design. These parts, the data and goals for the final AEV, help attain the goal of this lab, which is to further narrow down a design for the group to use as a finished product.
Lab 06 and 07 were not labs that involved testing the AEV or collecting. They functioned as checkpoints for the team to present their current plans for the final AEV design and receive feedback/questions from the instructional staff and from fellow classmates. The purpose of the labs were to give the groups a proper amount of critique to apply to their plans for the final AEV design.
Lab 08 A/B/C, it marked the beginning of the groups having lab meetings 3 times a week. For lab 08 the task given was have two designs, test run them, and compare the data of each to see which one runs better. This process involved testing the AEVs on a full run around the track and the collecting the data from these runs. Once this data is collected, it is then analyzed and used as a basis in choosing one design over the other.
Results
The team was able to incorporate all the data received from all the previous labs to produce this lab report and provide an in-depth analysis of the situation the team is currently in with the AEV project. Below is Figure 1, which describes which propeller configuration produced the greatest thrust at a certain percentage of power. Figure 2 below that shows the propulsion efficiency vs. advance ratio for the 3030 pusher configuration.
Figure 1: Thrust produced vs. power in the wind tunnel for different propeller configurations.
Figure 2: Propulsion efficiency vs. Advanced ratio for the 3030 pusher configuration.
Figure 3 below shows the initial orthographic drawing for the AEV concept discussed by the team in Lab 03. This design was a cumulation of the the team coming together to brainstorm an idea for the AEV. the initial concept incorporated two ideas: the A-wing from Star Wars and a bird known as the Alpine Swift, which has the ability to fly for hours on end. Table 1 below Figure 3 shows the sample scoring matrix of each team member’s individual design, as created after Lab 05.
Figure 3: The team’s orthographic design idea for an initial design of the AEV.
Table 1: Sample Scoring Spreadsheet for each team member’s individual design (Lab 05)
| Success Criteria | Reference AEV | Design 1 | Design 2 | Design 3 | Design 4 | Overall
Design |
| Balanced turns | 0 | + | + | – | – | + |
| Minimal Blockage | 0 | 0 | 0 | – | – | – |
| Center of Gravity | 0 | 0 | + | + | 0 | + |
| Maintenance | 0 | 0 | – | 0 | + | – |
| Durability | 0 | – | – | – | 0 | 0 |
| Cost | 0 | – | – | – | – | – |
| Environmental | 0 | + | + | + | + | + |
| Sum +’s
Sum 0’s Sum -’s |
0
7 0 |
2
3 2 |
3
1 3 |
2
1 4 |
2
2 3 |
3
1 3 |
| Net Score | 0 | 0 | 0 | -2 | -1 | 0 |
| Continue? | Combine | Combine | Combine | No | No | Yes |
Figure 4 below shows the graph for the power vs. time plot for the AEV sample test run. This test was initially thought to be one of the tests downloaded from the Arduino nano microcontroller but in fact was the default EEPROM data given in the performance analysis folder. This graph shows the breakdown of incremental energy into seven phases, which the team assumes to be only measuring the data of getting the AEV to the first part of the track, just before the gate. Table 2 below shows the breakdown of this incremental energy with it’s respective code.
Figure 4: Phase breakdown of Power vs. Time graph based on EEPROM data (Test_Data.mat)
Table 2: Phase breakdown of Power vs. Time graph with corresponding incremental energy (J)
| Phase | Arduino Code | Time (seconds) | Total Energy (Joules) |
| 1 | celerate(4,0,30,2); | 2 seconds | 6.67 |
| 2 | motorSpeed(4,20);
goToAbsolutePosition(197); |
~ 5 seconds | 25 |
| 3 | brake(4);
goFor(1); |
1 second | 0 |
| 4 | celerate(4,0,30,2); | 2 seconds | 6.3 |
| 5 | motorSpeed(4,20);
goToAbsolutePosition(369); |
2.5 seconds | 15 |
| 6 | reverse(4); | ~ 0.2 seconds | 0.75 |
| 7 | motorSpeed(4,30);
goFor(1.5); |
1.5 seconds | 13.05 |
Total Energy: 66.77 Joules
Tables 3 and 4 below show the concept screening and scoring matrix for the two new AEV designs that the team came up with after the Preliminary Design Report presentation. The two designs included a lightweight design that was shaped more like a conventional plane and a more balanced, heavier design that was designed to be vertical (however, lighter than the one that was come up with in Lab 03). These were compared to the original reference AEV and the AEV designed in lab 03. The results after the recent performance tests are shown below.
Table 3: Sample Scoring Spreadsheet for final results of the two new designs, compared with the current design and the reference AEV
| Success Criteria | Reference AEV | Current Design | New Design #1 (horizontal ‘aeroplane’) | New Design #2 (vertical design) |
| Balance | 0 | 0 | 0 | + |
| Mass | 0 | – | + | + |
| Center of Gravity | 0 | – | – | + |
| Aesthetics | 0 | + | – | + |
| Durability | 0 | + | + | + |
| Environmental | 0 | – | + | + |
| Cost | 0 | 0 | 0 | 0 |
| Sum +’s | 0 | 2 | 3 | 6 |
| Sum 0’s | 7 | 2 | 1 | 1 |
| Sum -’s | 0 | 3 | 2 | 0 |
| Net Score | 0 | -1 | 1 | 6 |
| Continue? | No | No | No | Yes |
Table 4: Sample Scoring Matrix for the expected results of the two new designs, compared with the current design and reference AEV
| Reference AEV | Current Design | New Design #1
(horizontal ‘aeroplane’) |
New Design #2 (vertical design) | ||||||
| Criteria | Weight | Rating | Score | Rating | Score | Rating | Score | Rating | Score |
| Balance | 25% | 3 | 0.75 | 3 | 0.75 | 3 | 0.75 | 5 | 1.25 |
| Mass | 25% | 4 | 1 | 2 | 0.5 | 4 | 1.0 | 4 | 1.0 |
| Center of Gravity |
20% | 2 | 0.4 | 3 | 0.6 | 2 | 0.4 | 5 | 1.0 |
| Aesthetics | 10% | 3 | 0.3 | 3 | 0.3 | 2 | 0.2 | 4 | 0.4 |
| Durability | 5% | 3 | 0.15 | 4 | 0.2 | 4 | 0.2 | 5 | 0.25 |
| Environmental | 10% | 2 | 0.2 | 1 | 0.1 | 5 | 0.5 | 5 | 0.5 |
| Cost | 5% | 5 | 0.25 | 5 | 0.25 | 5 | 0.25 | 5 | 0.25 |
Total Score |
3.05 | 2.7 | 3.3 | 4.65 | |||||
| Continue? | No | No | No | Yes | |||||
Figure 5 and Table 5 both show the performance analysis on the new design of our vertical AEV. Figure 5 shows a graph of power vs. time divided into 6 phases (color-coded) for an entire AEV test run; the team was unable to perform a power vs. distance run as the reflective sensors were not installed on this new design as of yet. The table below shows the division of the AEV test run into 10 phases with their respective incremental energies and code used to run that segment of the AEV test run. (See discussion for the reason why the team was unable to perform a performance analysis on our other horizontal ‘aeroplane’ AEV design.)
Figure 5: Performance Analysis of a successful test run for the vertically design AEV.
Table 5: Phase breakdown of Power vs. Time graph with corresponding incremental energy (J)
| Phase | Arduino Code | Time (seconds) | Total Energy (Joules) |
| 1 | reverse(1);
motorSpeed(4,30); goFor(6.1); |
6.1 | 7.0 * 6.1 = 42.7 |
| 2 | celerate(4,30,0,2);
brake(4); |
2 | ½ * (8.1-6.1) * 7 = 7 |
| 3 | goFor(6.5); | 6.5 | 0 |
| 4 | motorSpeed(4,30);
goFor(6.5); |
6.5 | (21.1-14.6) * 11.8 = 76.7 |
| 5 | brake(4);
goFor(9); |
9 | 0 |
| 6 | reverse(4);
motorSpeed(4,45); goFor(7.25); |
7.25 | (37.35-30.1) * 11.8 = 85.55 |
| 7 | celerate(4,45,0,2); | 2 | ½ * (39.35-37.35) * 11.8 = 11.8 |
| 8 | brake(4);
goFor(8); |
8 | 0 |
| 9 | motorSpeed(4,45);
goFor(8); |
8 | (55.35-47.35) * 11.67 = 93.36 |
| 10 | brake(4); | ~4 | 0 |
Total Energy: 317.11 Joules
Discussion
The team found that the most efficient configuration for the propeller was the 2510 puller configuration, which consistently gave a higher thrust as the power in the wind tunnel was increased. In fact, the team found that the 2510 propeller in both the puller and pusher configuration consistently produced better results in terms of thrust produced vs. the power in the wind tunnel. The ratio of power input vs. power output were also much greater for the 2510 configuration when compared to the 3030 propeller configuration. However, due to physical constraints and the fact that the 3030 propeller kept flying off of one of our AEV motors, this led the team to be forced to use the 2510 propeller configuration and find a way to make the AEV more efficient with this constraint.
In Lab 03, where the team was required to think creatively and brainstorm for an idea out of the box, the team came up with a design that was thought to be efficient, balanced and produce steady results for the team. However, the team found soon that after the design had been implemented, the team found that this AEV was in fact not only very inefficient (which was expected), but was also imbalanced on the AEV track, did not move well enough and was not aerodynamic nor produced good results. It was a design that had many complications to it, and so the team had to move away from that design idea in order to produce an AEV that would perform the job as required in the Mission Concept Review (MCR). The image for this AEV is shown below (figure X):
Figure X: The team’s first concept/design as brainstormed in Lab 03.
For the progress report written before the first performance test (for lab 08), the team came up with two new ideas that would be more efficient, balanced, aerodynamic and better engineered to perform the objective of the lab, which is to rescue the R2D2 within the allotted time frame of 2 minutes and 30 seconds. The first one would be mainly emphasized on being lightweight and ensuring that the center of mass was directly below the point in question. The second design mainly incorporated the idea of making the AEV balanced, even if it required the AEV to be slightly more heavy than that of our first design. This design was to be a lot more lightweight than the AEV designed in the brainstorming lab (Lab 03).
The two design concepts the team decided on creating was a horizontal, conventional ‘plane’ model, which was based off the model that we currently had, albeit much lighter. This was to serve as the more lightweight AEV design, as the team believed that the wheels would be situated much more evenly on the track when placed there and the wheel marks would be recorded as the wheels turned on the track (and therefore the absolute and relative position functions could be used). The problem faced with this model was that it was not balanced enough – similar to our initial design that the team came up with and modeled. The second model was a more vertical model which was to be a more balanced design. However, it seemed as though this model proved to also be more lightweight, efficient and move better overall on the track as the center of gravity was situated almost directly between the wheels, which meant that the wheels rested fairly on the track and was able to turn freely as the team uploaded code onto the Arduino nano microcontroller.
As a result, the team was able to perform a complete test run of the AEV to stop at the gates for the required amount of time and pick up the R2D2. This data was then downloaded to perform a performance analysis of the vertical AEV. However, due to the complications faced by the team in making the other lightweight horizontal AEV to start moving on the test track, even as the motorSpeed was increased drastically, the team was unable to perform a test run and therefore unable to perform a performance analysis of our horizontal ‘aeroplane’ AEV design. The images of both AEV’s are shown below.
Figure Y: The ‘aeroplane’ design concept (an extension of the A-Wing and Alpine Swift combination)
Figure Z: The vertical design concept (a completely new design where the team may incorporate some of the previous brainstorming ideas onto)
As can be seen from the performance analysis of the AEV run, the run required a power input of approximately ~317 joules. As we have no data essentially to compare it to (as the team used sample EEPROM data for the performance analysis in Lab 04), the team cannot deduce whether this is a good amount of energy used or not. However, if we assume that the sample data recorded for the performance analysis was only the first part of the track, it means that it had used up an average of 66.77 joules * 4 (considering there are 4 sections of the track to complete) which is equivalent to a total energy input of 267.04 joules. This is slightly more than the amount of energy expended by our current AEV, which means that it is not as efficient as the team would like, but it also seems that it is not expending more energy than is necessary to complete the mission. However, the team may need to modify the code in order to make it more energy efficient.
As a result of the team’s findings, the team decided to continue to use the vertical design. Most of what the team had decided on (A-Wing design with an Alpine Swift combination) was to be scrapped as it would make the AEV more heavy, inefficient and even less balanced (refer to the concept scoring and screening matrices in the Results section). The more lightweight and simple aeroplane design did not prove to be effective either, as there seemed to be a discrepancy with balancing the wheels onto the AEV track. This made the team decide to discontinue with that idea and use the vertical design as shown above. However, the team will make an effort to incorporate some of the previous ideas to meet the needs of each individual team member, and may 3D print a model for increased balance and aesthetics. Both SolidWorks 3D models and orthographic projections are shown in the Appendix.
Conclusion and Recommendations
The group determined several different things from results in testing the AEV. One was that the 3030 pusher propellers should be used, due to them moving the AEV with less power than the 2510 propellers. Another was that using time instead of absolute position seemed to work better for the group due to the malfunctions in the reflectance sensors.
The design the group will continuing testing with in the future is a vertical design, which proved to be more balanced, used less power, and was lighter. The group only needed 30% power to make the AEV reach the caboose, and 45% power. The other design did not even make a run on the track due to lack of balance between the wheels. Any attempt at fixing this problem was ineffective, as every change made would still have the AEV resting on one wheel instead of two. Because of this, a run on the track was impossible, so it could not be efficient at any of the requirements necessary for this lab. The vertical design will also allow the group to easily add the 3D printed wings for the AEV, which will mean less time will be spent assembly the wings and more time will be spent on testing and refining the AEV until all requirements are met.
As said before, the reason for the lack of data from the first design was that a run could not be achieved on the track because of weight balance issues. The group tried to resolve this issue by placing the Arduino and battery in different spots on the base of the AEV, as well as moving the arm of the AEV in different spot in an effort to distribute the weight so that when placed on the monorail, the AEV would balance on two wheels. All of these attempts were unsuccessful, and the group determined it would be better if the next design was tested rather than spend too much time on a design that would be too heavy on a track and would be inefficient. The group learned that weight distribution should be the highest priority when making a new design, because if the AEV was not balanced, any runs at all would be unable to be achieved. Another recommendation for future labs was to spend more time developing a solid plan of what the group wanted to accomplish in lab outside of class, so that more of the limited in-class time would be spent testing and collecting data.
Appendix
Appendix A
| No. | Task | Start | End | Due | Eric | Omar | Xander | Matt | % Complete |
| 1 | Project Portfolio | 1/19 | 4/19 | 4/20 | x | x | x | x | 70% |
| 2 | Finish AEV design | 1/19 | 4/12 | 4/13 | x | x | x | x | 80% |
| 3 | Complete AEV code | 1/19 | 4/12 | 4/13 | x | x | x | x | 50% |
| 4 | PDR Report | 3/21 | 3/26 | 3/27 | x | x | x | x | 100% |
| 5 | Progress Report 10 | 3/31 | 4/2 | 4/3 | x | x | x | x | 0% |
| 6 | CDR Presentation Draft | 4/1 | 4/5 | 4/6 | 0% | ||||
| 7 | Progress Report 11 | 4/7 | 4/9 | 4/10 | x | x | x | x | 0% |
| 8 | Extra Credit Video | 4/8 | 4/12 | 4/13 | 0% | ||||
| 9 | CDR Report | 4/11 | 4/19 | 4/20 | x | x | x | x | 0% |
| 10 | CDR Presentation | 4/14 | 4/19 | 4/20 | x | x | x | x | 0% |
Appendix B-SolidWorks Models
Design #1 -Horizontal Aeroplane
Design #2 -Vertical Design
Appendix C – Arduino Code (used for full run – design #2):
reverse(1); //Reverse motor number 1.
motorSpeed(4,30); //Power all motors to 30% speed.
goFor(6.1); //Maintain 30% speed for 6.1 seconds.
celerate(4,30,0,2); //Decelerate all motors from 30% speed to 0% speed in 2 seconds.
brake(4); //Brake all motors
goFor(8); //Continue to brake for 8 seconds.
motorSpeed(4,30); //Power all motors at 30% speed.
goFor(6.5); //Maintain 30% speed for 6.5 seconds.
brake(4); //Brake all motors.
goFor(9); //Continue to brake for 9 seconds.
reverse(4); //Reverse all motors.
motorSpeed(4,45); //Power all motors to 45% speed.
goFor(7.25); //Maintain 45% speed for 7.25 seconds.
celerate(4,45,0,2); //Decelerate all motors from 45% speed to 0% speed in 2 seconds.
brake(4); //Brake all motors.
goFor(8); //Continue to brake for 8 seconds.
motorSpeed(4,45); //Power all motors to 45% speed.
goFor(8); //Maintain 45% speed for 8 seconds.
brake(4); //Brake all motors.