Executive Summary
The main goal of this project was to create an AEV that would travel along a monorail across the planet Hoth. The AEV would have to travel from a base to a gate, wait seven seconds at the gate before it would open, then travel the rest of the monorail track to pick up an R2 unit that would be on a caboose. When the AEV made contact with the caboose, the vehicle would wait five seconds for cargo to be inspected, then the AEV would make its return journey on the monorail, again stopping at the gate for seven seconds, and then returning to the base. The group’s overall goal was to create a design that fulfilled all of these requirements. The objectives the team focused on were created a lightweight design with a strong center of gravity.
One of the research methods used by the group was having group members create AEV designs individually and as a group, and the best designs would be used for further testing. Doing this type of research allowed the group to obtain a wide variety of results for the AEV, such as efficiency, mass, center of gravity, durability, and aesthetics. These results were put into screening and scoring matrices so they could be easily compared. Another research method developed was using different types of code with the AEV. By having multiple codes, the group could easily compare the energy consumed by the AEV and also how well it ran on the track. Both of the previous research methodologies were used after a near final design and code was created to optimize efficiency as much as possible. By seeing what improved efficiency in the past, the group could use that same thought process to slightly increase the efficiency of the final design.
Performance Test 1 focused on comparing two designs and deciding on a final design. The two designs created were a horizontal design and a vertical design. The screening and scoring matrices showed that the horizontal design had a good mass, but the center of gravity, durability, aesthetics, and efficiency were not very good. However, in contrast, the vertical design excelled in all of the categories mentioned before. These results helped the group obtain the final design because it was evident after these tests that the vertical design was the best design that would optimize efficiency. Performance Test 2 focused on creating two different codes, one time based and one position based. The group’s attempt at creating a code using position proved to be extremely challenging, due to the reflectance sensors not functioning properly and the reflectance sensors not being long enough to plug into the Arduino at the bottom of the AEV. The time based code proved to work better for the group, while it may not have been as accurate as position based code could have been, time based code was the only thing that would work somewhat consistently. After this performance test, all of the code would be time based. Performance Test 3 simply focused on developing the most energy efficient code possible. The group experimented with using different amounts of power throughout the run, and found that using a little more power at the beginning of the run was more efficient than using less power because using more power meant that the motors were on for less time, which used less energy. This same thought process was applied to bringing the AEV back with the caboose, which required more power than the first half of the run due to the increased weight of the caboose. All of the results gathered from Performance Tests 1-3 helped the group decide on a vertical design with a time based code using slightly more power in the beginning of the run so that the motors would be on for less time. This would prove to be the most efficient design that the group could come up with before final testing of the AEV.
Introduction
Over the course of the semester, the main goal of the team was to fulfill the requirements listed in the MCR, which were to create an energy efficient AEV design that would travel across the monorail track, stop halfway at a gate for seven seconds, continue to travel along the track, pick up a caboose, wait five seconds for cargo to be inspected, travel halfway and stop at the gate for seven seconds again, and then proceed to travel to the original position. The group mainly wanted to focus on creating a lightweight design because the thought process was the less the AEV weighs, the less power that will be needed to make it complete the run.
The group created an AEV design and made a code that would fulfill the requirements of the MCR and would optimize efficiency. The group ultimately came up with a lightweight design with a good center of mass that would make traveling on the track easier. The code written was based on time, which was meticulously tested to determine how long the motors would need to be on for the AEV to stop in the right places at the exact right time. After creating and designing all of the previously mentioned items, the group was able to make a near perfect run, with the only flaw being that the AEV was unable to fully travel all the way back to the original starting position, but it made it mostly back.
Experimental Methodology
Throughout the 12 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).
Figure A: A concept design from lab 03
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.
In labs 09a, 09b, and 09c, the team was tasked with focusing on the code being used with the chosen design. The main goal of these labs was to create two different codes, one using time and one using the reflectance sensors and distance. The team would perform two complete runs with the different codes and compare the two based on the consistency of the runs, how the code works on separate tracks, and the how energy efficient each code was.
In labs 10a, 10b, and 10c, the team began to work exclusively with time-based code, due to the group having more success with it that with position based-code. The goal of this lab was to optimize the code for the AEV and make it as efficient as possible. The group ran many test runs throughout this lab, using various different programs throughout to determine which programs allowed the AEV complete the MCR while using the smallest amount of energy. One of these approaches included using a high motorSpeed for a short time, then coasting for the rest of the run. Another involved reversing all motors right before the gate. The servomotor was also implemented at one point, as the team also experimented with new hardware to discover if it provided extra efficiency for the AEV.
Lab 11 was reserved for the final testing of the AEV. The AEV was tasked with performing a run. During this run, the time it took to complete it would be taken and recorded. The total energy used and mass of the AEV with battery would also be recorded.
Results
Figure 1 below shows the results obtained from Lab 02b’s test when comparing the power generated by the different configurations of the propellers and the types of propellers. For our graph, it seems as though the greatest amount of power was generated by the 2510 pusher, which generated a thrust of approximately 270 grams. The other three seemed to be relatively similar, with the 2510 pusher coming in second strongest, and the 3030 puller and pusher coming in third and fourth respectively.
Figure 1: Thrust produced vs. power in the wind tunnel for different propeller configurations.
Figure 2 below shows the graph generated for the propulsion efficiency vs. Advance ratio for the 3030 pusher configuration. The graph seems to show a maximum propulsion efficiency of 25% for an advance ratio of 0.3, which implies that a motorSpeed of 25% would essentially save the most energy if our AEV used the 3030 pusher configuration. However, the team found that this motorSpeed just does not generate enough speed to start to move the AEV, which is explained in the Discussion section of this lab report.
Figure 2: Propulsion efficiency vs. Advanced ratio for the 3030 pusher configuration.
Figure 3 below shows the orthographic drawing of the initial concept design for the AEV during the brainstorming session of Lab 03. The initial design was intended to be an A-wing and Alpine Swift combination, which mainly takes into account the Aesthetics. However, this idea was discontinued due to the fact that it was unbalanced, inefficient and very heavy and costly.
Figure 3: Orthographic drawing of Team C’s original brainstormed AEV design.
Table 2 below shows the concept scoring spreadsheet for the team’s two proposed designs in turn compared with the original proposed AEV design along with the reference AEV. The two proposed designs included the horizontal ‘aeroplane’ design and the vertical design. These two designs were compared for how effective they were in terms of their aesthetics, balance, center of gravity and mass among other factors. Below that is Table 3, which shows the concept screening matrix which puts the weight of each of those factors into context. The team found that the vertical AEV design was a lot better in balance, center of gravity, and mass when compared to the horizontal AEV design.
Table 2: Sample Scoring Spreadsheet for the horizontal and vertical designs compared with the proposed and reference AEV designs.
| Success Criteria | Reference AEV | A-Wing +
Alpine Swift AEV |
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 |
| Sum +’s | 0 | 3 | 3 | 6 |
| Sum 0’s | 7 | 1 | 1 | 1 |
| Sum -’s | 0 | 3 | 2 | 0 |
| Net Score | 0 | 0 | 1 | 6 |
| Continue? | No | No | No | Yes |
Table 3: Sample Scoring Matrix for the expected results of the two new designs, compared with the current design and reference AEV
| Reference AEV | A-Wing +
Alpine Swift AEV |
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 | 3 | 0.15 | 5 | 0.25 | 5 | 0.25 |
Total Score |
3.05 | 2.6 | 3.3 | 4.65 | |||||
| Continue? | No | No | No | Yes | |||||
As per Table 3, it was made clear that the vertical AEV design was far more superior to that of the horizontal ‘aeroplane’ AEV design. The vertical design got perfect ratings for the factors that weighed the heaviest, mainly balance, center of gravity and aesthetics. The mass, durability, cost and its environmentally friendly design matched that of the horizontal AEV design. These results from the concept screening and scoring matrices led the team to continue with the vertical AEV design.
Figure 4 below shows the performance analysis data for the team’s complete and successful run received during Labs 08A-08C. The graph is a Power vs. Time graph as the team ran the AEV test run using time instead of relative position in the Arduino code. The graph is divided into 10 phases. The phase breakdowns of the AEV are given in Table 4, which show the code used for each phase and the amount of energy expended during each phase.
Figure 4: Power vs. Time graph of a complete and successful run using time for the vertical design.
Table 2: 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
Figure 5 below shows the final performance analysis recorded for Team C’s final AEV test run. The graph is also a Power vs. Time graph as the team’s final code implemented time rather than position (for reasoning on why the team decided to use time rather than relative position, refer to the discussion). The graph is divided into 7 phases, and the breakdown of each phase is given in Table 5 below the figure with it’s respective code and incremental energy. Each phase breakdown comes with it’s respective code, the time spent in that phase as well as the calculated incremental energy for that phase. The total amount of energy expended is given below Table 5.
Figure 5: Power vs Time graph for Team C’s final test run using the vertical design.
Table 5: Phase breakdown of the final test run with each phases’ respective code and incremental energies.
| Phase | Arduino Code | Time (seconds) | Total Energy (Joules) |
| 1 | reverse(2);
motorSpeed(4,30); goFor(6.3); |
6.3 | 7.5 * 6.3 = 47.25 |
| 2 | celerate(4,30,0,2.2); | 2.2 | ½ * 2.2 * 10.67 = 11.74 |
| 3 | goFor(10);
reverse(4); |
10 | 0 |
| 4 | motorSpeed(4,30);
goFor(6.2); |
6.2 | 7.5 * 6.2 = 46.5 |
| 5 | reverse(4);
celerate(4,30,0,2); |
2 | ½ * 2 * 11 * = 11 |
| 6 | goFor(9); | 0 | 0 |
| 7 | motorSpeed(4,50);
goFor(7.2); |
7.2 | 13.3 * 7.2 = 95.76 |
| 8 | celerate(4,50,0,2); | 2 | ½ * 2 * 13.3 = 13.3 |
| 9 | goFor(10); | 0 | 0 |
| 10 | motorSpeed(4,45);
goFor(9); celerate(4,45,0,1); |
10 | 12.5 * 9 = 112.5 |
Total Energy: 338.05 Joules
Discussion
As you can see from Figure 1 above, the graph for the propeller efficiencies show that the 2510 propeller seems to have been better than the 3030 propeller in both the pusher and puller configurations. However, through multiple test runs, the team had actually found that the 3030 propeller was in fact a better fit to move the AEV as the diameter of that type of propeller spanned a greater distance. The team found that there was a higher thrust produced for a given amount of weight with the puller configuration, and the team took this into account into the final two design concepts that the team had brainstormed and created during Labs 08A-C. In addition, as per Figure 2 above, the highest propulsion efficiency was found to be at a motorSpeed of approximately 25%. Due to complications with moving the AEV at this speed, the team had to rely on increasing the speed by approximately 10% to a total speed of 35% in order to get the AEV to move efficiently and properly.
After finding that the original brainstormed design of the A-Wing and Alpine Swift combination was not as efficient and was heavy, cumbersome and going to be expensive to produce, the team had decided to move towards two simple yet very efficient designs for the AEVs. The first design was a horizontal ‘aeroplane’ design, which was similar to the original design except that it was light-weight, more balanced and held a steady position on the track. The next design was not similar to anything the had worked on previously; it was a vertical design that the team had decided to test out to compare the two new designs. This new design was also expected to be light-weight, balanced, have a low and steady center of gravity and be much more balanced on the track when compared to our original brainstormed design.
As can be seen from the concept screening and scoring matrices in Tables 2 and 3 in the ‘Results’ section, the vertical design was by far the better design when compared to the horizontal design. As a result of continuous testing, the team had determined that the most important factors that will weigh in for the biggest percentages (as per the concept scoring matrix of Table 3) were going to be how well the AEV balanced on the track, the AEVs weight, the AEVs center of gravity and whether or not it was aesthetically pleasing to look at.
The team had found that the vertical design by far better than the horizontal design when it came to its balance on the track and how low it’s center of gravity was to maintain its position on the track and not fall or fly off. In addition, the vertical design was a lot more aesthetically pleasing to look at. Both AEVs were light-weight, but the team had decided to scrap our initial idea of the A-Wing and Alpine Swift combination and continue to work with the vertical design that the team had created. Images of the original design, the horizontal design and the vertical design are shown below. The SolidWorks models for both of our new designs given in the Appendix along with their respective bill of materials and estimated weight and cost.
Figure B: Team C’s original design, based off of the A-Wing and Alpine Swift combination.
Figure C: The horizontal ‘aeroplane’ design concept created by Team C (battery holder detached).
Figure D: The vertical AEV design concept created by Team C.
After the team had found out that the vertical design was best to continue with, the team had initially planned to 3D print a part for this vertical AEV design. The 3D printed object would serve as an increased balancing mechanism. However, there seemed to be more disadvantages with 3D printing this part and adding it onto our AEV design rather than leaving the vertical AEV design the way it was originally created. While it may have increased the overall balance of the AEV and provided increased aesthetics, it was going to increase the overall cost associated with the AEV in addition to increase the overall weight of the AEV. Not only that, but the fact that our AEV physically did not have enough space for the team to install the 3D part meant that the team was going to have to completely redesign the AEV and add new parts in order to fit the 3D part. This in turn was going to require big changes to our code. The team had been using time instead of relative position, and increasing the weight meant that the AEV was not going to behave the way the team expected it to (i.e. it was not going to stop at the correct locations, like before the gate). Since the team was approaching testing day, the team had decided it was best to forget about 3D printing a part and focus more on our code to get a successful run and make our AEV more efficient.
That is one of the ways the team decided to cut overall costs. The team had actually not considered costs to be much of a factor. As can be seen from the concept screening matrix, the team had only weighed cost at approximately 10%. This was because taking the more important things into account for our two new designs (e.g. balance, mass and center of gravity) meant that the team would be using fewer parts from the AEV kit as well as external sources, which as a result decreased overall costs for our AEV. In fact, as can be seen in the Appendix under the Bill of Materials for both of our AEV designs, both the horizontal and vertical designs costed approximately the same, around $143.34 and $143.06 respectively.
When the team conducted its first performance analysis test, the team did so using time in the Arduino code rather than relative position. This was due to the many complications faced with using the reflective sensors. For example, whenever the team decided to test the AEV using the ‘Serial Monitor’ on the AEV software, many times the reflective sensors would not be detected. However, whenever it was and the team uploaded that code onto the Arduino nano microcontroller, the team found that the AEV would actually not stop when the number of marks was reached. In fact, the team had even tried to test the AEV at around 10 marks, and even when the AEV would move this distance (which is less than 1 foot in length), the AEV would still keep going. This made the team move towards using time in our code and going through trial and error in order to get the AEV to stop at its respective locations.
However, one of the biggest disadvantages with using time was that it was not reliable; the AEV would need to be positioned in such a way that it would not be interrupted by any tape on the track and would go through all the guidelines as stated in the Mission Concept Review. In addition, if there was any weight added on or any modifications made to the AEV, the team would need to go through the entire code to make sure the AEV stops when it needs to (i.e. before tripping the gate sensors, picking up the R2D2/caboose, etc.). For Team C’s first performance analysis as shown in Figure 4, the team was able to get a complete and successful test run using time in our Arduino code. The graph is a Power vs. Time graph which is divided into 10 phases, and the respective code for each phase as well as the incremental energies are displayed on Table 2. The team had found that the total energy expended for this entire run was approximately 317 joules, and the team’s goal from this point onward was to make the AEV more efficient than this for our final performance run.
Unfortunately, that goal was unable to be achieved. For our final performance analysis, as shown in Figure 5 for the Power vs. Time graph of our final successful test run, the team had actually expended slightly more energy than anticipated. This can be seen on Table 5, which shows the breakdown of each phase with their respective code and incremental energy. The team had expended approximately 338-339 joules of energy for this run, whereas in our old run the team had expended 317 joules. There were two main reasons why the team had expended slightly more energy for the final performance test when compared to the previous successful performance test. The first reason was that the team had made our stops more crisp and clean and more reliable. The team had initially depended on the AEV to coast to a stop. However, after finding that this was extremely unreliable, the team had decided it was best to include a decelerate function by reversing the motors and accelerating backwards to stop before the gate and R2D2/caboose. As a result, the overall energy expended was increased, but the AEVs run was made more reliable. In addition, the team had to increase the overall motorSpeed in bringing the caboose/R2D2 back from enemy territory back to base. The team initially had the motorSpeed function at 45%, but due to multiple tests where the AEV would be unable to pull the R2D2/caboose back towards the gate and then to base meant that the team had to increase the overall speed to 50%. Again, this increased overall energy usage, but in the end gave the team more reliable results.
For our final run, the team had thankfully been able to get a complete and successful run, albeit using slightly more energy for our final performance analysis when compared to our initial performance analysis (as explained above). Team C’s vertical design AEV moved from the first part of the gate and stopped slightly before the sensors for the first part of the gate, and decelerated backward successfully to the first sensor but not the second one. After waiting for around 7-8 seconds, the AEV then moved to pick up the caboose/R2D2, decelerated and waited successfully for 5 seconds to make sure all cargo was loaded. The AEV then brought the R2D2/caboose back to the first part of the gate, and almost tripped the second sensor and cause our test to fail, but it just stopped right before the second sensor. At this point ¾ of our run was a success. However, the team miscalculated our final goFor time and the AEV stopped slightly short of bringing the R2D2/caboose back to base, and the team lost 2 points for this as can be seen from the scoresheet in the Appendix. Our total run time was approximately 82.5 seconds (1 minute and 22.5 seconds), which exceeded the requirement of 2 minutes and 30 seconds by an entire minute as was laid out in the Mission Concept Review (MCR). Therefore, the team was able to complete the guidelines as stated in the MCR, and although the team had expended slightly more energy than expected , the team was able to get a successful AEV run and meet all the requirements except on the last portion of the track where the AEV failed to get the R2D2/caboose back to the base.
Conclusion and Recommendations
The group learned several things from the AEV testing. One was that the vertical design provided the optimal efficiency and best weight distribution. It was also found that using time instead of position worked better for the team due to the malfunctioning in the reflectance sensors. The AEV was found to be slightly more efficient in its power usage when it started at a higher power rather than a lower power due to the motors being on for less time.
Time was decided to be used over position because of numerous reflectance sensor problems. The main issue was that the sensors did not record the marks correctly when up on the track, and it was difficult for the group to account for and correct this issue. Another problem was the sensors were simply not long enough to be plugged into the arduino and put under the wheel at the same time, which was because of the way the vertical design was set up. Using a higher power to start the run was proved to be more efficient than using less power. This was because having less power meant the AEV took longer to get to the gate, which meant the motors would be on longer. Through analyzing the data, it was determined that having the motors on for a longer time, even though it was a lower power, was less efficient than a code that had a slightly higher power being used in the beginning to make the time between starting point and gate shorter.
As mentioned before, the final design chosen was the vertical design and chosen for many reasons. One reason was that it accomplished the things the group wanted to focus on: low mass, excellent center of gravity, and low power usage. The vertical design had a minimalistic design which helped cut weight. This design had all of the weight hanging from the center of the arm of the vehicle, which meant that the center of gravity would be right in the middle of the vehicle, and both wheels would stay comfortably on the track. Since this design was lightweight, it did not take a lot of energy to get it moving, which helped lower the amount of energy required for the entire AEV run. This design is better than other designs in the class mainly due to its center of gravity and its ability to have consistent runs. While not every run landed right on the mark, each run was fairly close to hitting the sensors, either being just short or just too far. This meant that only minor adjustments needed to be made to the code, which helped the group significantly when making the final code because the range of times we needed to fit in steadily decreased.
One consistent error that the group came across was that the distance the AEV would travel one run would not be the same on the next run, even though it started in the same spot. This error was one of the drawbacks of using time based code, since many factors can affect distance on the track, such as the wheels turning at different rates or the battery not being as powerful as the previous runs. This error was overcome for the most part by creating a window that the AEV would hit the sensor almost half of the time. By doing this, the group felt confident that the code would work for at least one of the final tests.
The group would recommend ensuring that all of the reflectance sensors function properly before handing them out to groups. In the team’s experience, the reflectance sensors always seemed like they would provide more accuracy than using time, but the group was unable to test with them because they did not work properly. The final design of the AEV could have been even more efficient if proper reflectance sensors were provided. This would also provide future groups with more of a choice with having time, position, or a combination of the two in their code, rather than being forced to due time due to malfunctioning equipment.
The only thing that was incomplete at the end of the testing was creating a code in which the AEV traveled completely back to the starting position. The code written for the last quarter of the run had not been tested as extensively as the other ¾ of the code. This was because it took a lot of time to get the code for the first ¾ of the run to be correct, and when the time for final testing arrived, the group simply did not have enough time to test the last bit of code. The run was not a complete failure, as the AEV made it to the caboose, and passed through the gate successfully on both the forward and return journey, but the AEV was about a foot away from the original starting position.
Appendix
Appendix A-Team Meeting Schedule
Table A1: Project Schedule
| No. | Task | Start | End | Due | Eric | Omar | Xander | Matt | % Complete |
| 1 | Project Portfolio | 1/19 | 4/19 | 4/20 | x | x | x | x | 100% |
| 2 | Finish AEV design | 1/19 | 4/12 | 4/13 | x | x | x | x | 100% |
| 3 | Complete AEV code | 1/19 | 4/12 | 4/13 | x | x | x | x | 100% |
| 4 | PDR Presentation | 2/26 | 3/1 | 3/2 | x | x | x | x | 100% |
| 4 | PDR Report | 3/21 | 3/26 | 3/27 | x | x | x | x | 100% |
| 5 | CDR Presentation Draft | 4/1 | 4/5 | 4/6 | x | x | x | x | 100% |
| 6 | Extra Credit Video | 4/8 | 4/18 | 4/20 | x | x | x | x | 100% |
| 7 | CDR Report | 4/11 | 4/19 | 4/20 | x | x | x | x | 100% |
| 8 | CDR Presentation | 4/14 | 4/18 | 4/19 | x | x | x | x | 100% |
Appendix B- SolidWorks Models
Figure A1: Vertical Design Isometric and Orthographic views
Figure A2: Vertical Design Bill of Materials
Estimated Weight: 183g (228g with battery)
Estimated Cost: $143.06
Figure A3: Horizontal ‘Aeroplane’ Design Isometric and Orthographic Views
Figure A4: Horizontal ‘Aeroplane’ Design Bill of Materials
Estimated Weight: 191g (236 g with battery)
Estimated Cost: $143.34
Appendix C: Arduino Code
Initial Performance Analysis – Successful Run
1st Quarter Run:
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.
2nd Quarter Run:
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.
3rd Quarter Run:
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.
4th Quarter Run:
motorSpeed(4,45); //Power all motors to 45% speed.
goFor(8); //Maintain 45% speed for 8 seconds.
brake(4); //Brake all motors.
Final Performance Analysis
1st Quarter Run:
reverse(2); //Reverse all motors
motorSpeed(4,30); //Power all motors to 30% speed
goFor(6.3); //Maintain 30% speed for 6.3 seconds
reverse(4); //Reverse all motors
celerate(4,30,0,2.2); //Decelerate all motors from 30% speed to 0% speed in 2.2 seconds.
goFor(10); //Wait for 10 seconds
reverse(4); //Reverse all motors
2nd Quarter Run:
motorSpeed(4,30); //Power all motors at 30% speed
goFor(6.2); //Maintain 30% speed for 6.2 seconds
reverse(4); //Reverse all motors
celerate(4,30,0,2); //Decelerate all motors from 30% speed to 0% speed in 2 seconds
goFor(9); //Wait for 9 seconds
3rd Quarter Run:
motorSpeed(4,50); //Power all motors to 50% speed.
goFor(7.2); //Maintain 50% speed for 7.2 seconds
celerate(4,50,0,2); //Decelerate all motors from 50% speed to 0% speed in 2 seconds
brake(4); //Brake all motors
goFor(10); //Wait for 10 seconds
4th Quarter Run:
motorSpeed(4,45); //Power all motors to 45% speed.
goFor(9); //Maintain 50% speed for 9 seconds
celerate(4,45,0,1); //Decelerate all motors from 45% speed to 0% speed in 1 second
brake(4); //Brake all motors.
Appendix D-Final Scoresheet
