Posts

Performance Test 1 (3/10/2017)

Summary

There were several goals accomplished throughout labs 1-7 of this project. In lab 1, the team learned  how to program the AEV using the Sketchbook program. The team refined these skills by writing different programming scenarios. The next lab tested the propeller efficiency utilizing wind tunnel testing. The results revealed that the puller configuration is more efficient than the pusher configuration. Using this data, the team chose to design an AEV that utilizes a puller configuration for the propellers. In lab 3, each team member designed an AEV prototype by drawing orthographic projections. The team used these drawings to compare and decided on a group design AEV combining the best features from each prototype. The team then employed screening and scoring matrices to compare each design with the reference design and examined their performances in accordance with certain criteria decided on by the team.

The team then used the data analysis tool on Matlab to gather information about the performance of the AEV. The tool provided information about the voltage, current, time, and marks from the sensors. This data was used to construct a graph of power vs time to analyze the performance of the AEV and the different phases involved. In lab 6 of the project, the team had the time to test different codes on track. Different codes were written to make the AEV stop at the desired location and time. The team wrote the code using knowledge of basic commands like brake, and the fact that it doesn’t stop the AEV right away. The reverse command was used to reduce the speed by reversing the polarity of the motors for a short period of time then the brake command was used to cut the power from the motors. The team also used goToAbsolutePosition to manipulate the AEV to stop at the desired location. Finally, lab 7 was used to test the friction force between the AEV and the track. It was also used to test the accuracy and performance of the AEV by running it on the straight track and measuring the distance travelled. The team then analyzed the data from these trials using the data analysis tool. The team learned from this data that improvements had to be made to reduce the mark errors and have better control over the AEV.

Results

The team will be testing two design concepts this week. The first one is different from the reference AEV. The first difference is that there is no wings on the side of the base of the AEV. The team decided to have two small plastic arms come down from the bottom of the AEV, and the motors attached to the side of the arms. This allowed for a more lightweight AEV in comparison to the reference AEV while also being more aerodynamic. This also helped the weight be distributed more evenly and allowed the AEV to have a better center of balance while traveling on the rail. Design concept one also has the arduino on the bottom of the AEV and the battery and battery holder on the top of the AEV. This was put in place with the idea that the AEV would have to transport something, creating more room on top of the base of the AEV. This design uses the same base and L-shape arm to hold the AEV on the rail as the Reference AEV.

Design concept two is similar to design concept one, but with a few modifications. First off, The AEV is constructed on a smaller base. This allows the AEV to have less drag and more lightweight than both design concept one and the reference AEV. Design concept two has the arduino on the top of the base; however, there is no battery holder. The battery will be attached to the L-shape arm that holds the AEV onto the rail. This will also reduce the weight of the AEV. This design has only one small plastic arm coming out the bottom of the base of the AEV towards the middle with the motor strapped to it. The other motor will be screwed into the bottom of the base of the AEV in the front. The team decided to do this in order to increase the force from the propellers, making the AEV more energy efficient.

Both of these design concepts incorporate changes to the reference AEV that will make the AEV more energy efficient. Whether it is cutting weight or making the AEV more aerodynamic, every change that was made has a specific reason behind it. Having the AEV complete the specific tasks while using the least amount of energy is the ultimate goal, and to do this many changes have to be made to the reference AEV. The changes that design concepts one and two incorporated will be tested and data will be extracted in order to see how the changes affected the AEV. The team will hopefully find pros and cons of each design and then use these results to design an energy efficient AEV.

 

 

Team Meeting Notes

Date: 3-8-2017

Time: 6:00-7:50  pm

Members Present: Evan Berry, Alex Savelieff, Ahmed Negnm

Topics Discussed: Distributing parts of the lab report.

Objective: Identify who is taking which parts as well as getting a template set for the lab.

To do/Action Items: Split up each section between each other.  Plan for all the parts to be completed by Thursday night.

Decisions: Everyone will complete their part by Thursday night, any time, we will then meet Friday morning to wrap all the parts together and make the final copy, ready to turn in.

Date: 3-10-2017

Time: 8:30-9:30  pm

Members Present: Evan Berry, Alex Savelieff

Topics Discussed: Proofreading and finalizing the progress report

Objective: Ensure all parts are present and up to the team’s standards

To do/Action Items: Read through the entire document and ensure there are no major issues

Decisions: The progress report will be checked and turned in on time

 

 

The figure above depicts the concept screening scoresheet. This graph displays success criteria developed by the team which includes covering curves, blockage, center of gravity, durability, cost, environmental aspects, and efficiency. A score is given for each design and awarded a plus if the new design improves this area in comparison to the old design, a minus if it makes it worse, and a zero if it remains the same.

 

 

The figure above depicts the Concept Scoring Matrix, which describes the different success criteria using a weighted scale. Each criteria is rated on a scale of 1-5, and a weighted score is produced by multiplying the score by the weight. A total score was produced for each design. The reference design, Cameron’s design, and the group design were all rated using this method.

 

 

The figure above depicts the  code that was tested.

 

 

The figure above displays the teams revised code.

Lab 7 (3/7/17)

Summary

The AEV Energy Model Lab consisted of checking  that the wheel count sensors were working properly on the team’s respective AEV and calculating  the net force for the AEV from the data collected so the team could analyze the performance of the AEV. The team used troubleshooting if the recorded wheel counts were different from the actual wheel counts. Verifying accurate sensor readings are very important for the AEV in order to program the AEV to complete certain tasks at specific and exact locations along the track. The team will later use the results to create a more energy efficient AEV. The ability to design more energy efficient vehicle; hence, Advanced Energy Vehicle,  is essential in creating the best product possible, which will save the company operating the AEV money as well as reducing the amount of natural resources used and harmful gases put into the environment. The whole purpose of the AEV is to create a vehicle that can complete various tasks on a track while utilizing the least amount of energy. This lab deepened the team’s knowledge on how to do this and displayed the importance of conserving energy.

 

Results

The AEV had a total mass 0.256 kilograms as recorded in Table 1. There were 275 marks recorded by the sensors. However, after the distance of the AEV traveled was converted into marks the AEV actually went 282.3 marks as shown in Table 2. The team had a significant marks error of 7 marks, requiring the team to get assistance from an instructor. The team worked to resolve the issue but due to time constraints, no data was able to be collected using the improved sensors. Data from the AEV was then uploaded into MATLAB and various pieces of data were recorded and used to calculate the friction force and the propeller force. The friction force was 3.6 gram-force and the propeller force was 7.8 gram-force, as shown in Table 3. The propeller force displayed how powerful the fans were pushing the air back and the friction force exhibited the friction experienced by the AEV on the rail. The ideal AEV should have the lowest friction force and highest propeller force, resulting in the highest net force. The AEV had a lower propeller force compared to the 11.2 gram-force class average as evident in Table 1. The force of friction on the AEV was also lower than the 4.7 gram-force class average as evident in Table 1. This resulted in a 5.2 gram-force net force for the AEV compared to the 6.5 gram-force class average as evident in Table. A higher net force means better energy efficiency, and the AEV was over a point below the class average. The team discussed ways to make the AEV’s propeller create a larger force, but no ideas were executed in this lab. The team will troubleshoot and resolve these issues at later meetings.

There were many setbacks and errors that occurred during this lab. Initially, the code from Figure 1 would not upload to the arduino. The team realized that Sketchbook was connected to the wrong COM port. This was resolved by choosing the correct COM port for the arduino. Adding the code to the arduino was essential to completing the rest of the lab. This therefore took up much of the time and put the team in a rush to finish the rest of the lab. After the computer was successfully connected to the arduino and the code was added, the AEV did not move on the track. After troubleshooting the problem, the team realized the code was directly copied into the sketchbook program and did not include the reverse function needed to reverse the front motor to pull rather than push. This was necessary because the motors are in opposite directions. One potential source of error could have occurred when the measurements were taken on the track. Due to the length of the track and the quantity of teams testing their vehicles, different team members measured the startpoint and endpoint of the AEV. This division of work could have resulted in variations in where the AEV was measured by the two different people. While this error was minimized when the lab partners communicated which part on the AEV would be measured, the two lab members could have had measured slightly different locations within that part. This error could be eliminated by having one member measure both the startpoint and endpoint taking valuable time needed for other teams to test their AEV’s.

The lab procedure was in excel rather pdf. The format made it harder to follow. While data collection was easier to input, reading off the instructions was difficult. In order to decrease the amount of time teams spent waiting for  recommendation would be to set times throughout the lab time for each team to test the AEV. This would make for a more organized and efficient method of testing, and would help avoid confusion between different teams.

This lab allowed the team to observe the calculated and actual data points of the AEV in order to determine and fix issues with the wheel count sensors. It is important to verify accurate sensor readings for the AEV so that the AEV will be able to complete certain tasks at specific and exact locations along the track. Figure 2 shows the measured number of marks by the AEV compared to the actual marks the AEV traveled over each time interval. This graph shows how the data of each one differs which represents the error in the sensors. This lab displayed how the AEV compared to the rest of the class. The team’s AEV had a lower propeller force at 7.8 gram-force compared to the 11.2 gram-force class average. Also, the team had a friction force 3.6 gram-force, which was lower than the 5.2 gram-force class average. The team also had a net force of 5.3 gram-force in comparison to the class average of 6.5 gram-force. Additionally, the team had a marks error of 7 which was higher than the class average and will need to be corrected.  A more efficient AEV is created with a higher net force, as demonstrated during the lab. The team will need to troubleshoot and make use of problem solving techniques in order to increase the net force in order to create a more energy efficient vehicle.

 

Mass of the AEV 0.256 kilograms
Starting point 24.00
Ending Point 160.00
Actual Marks 282.3

Table 1

 

 

Marks recorded by sensors 275 marks
Marks Error 7 marks
Distance traveled by AEV 3.45 meters

Table 2

 

 

Time when motors stop 4 seconds
Marks when motors stop 132 marks
Distance when the motors stop 1.616 meters
Time when the AEV stops 12.18 seconds
Marks when the AEV stops 275 marks
Distance when the AEV stops 3.366 meters
Average velocity 0.404 m/s
 Max velocity 0.808 m/s
Acceleration constant motor speed 0.099 m/s2
 Acceleration for coasting 0.202 m/s2
Friction force 3.6 gram-force
Net force 5.3 gram-force
Propeller force 7.8 gram-force

Table 3

 

 

motorSpeed(4,30);    // Sets all motors to 30% power

goFor(4);                      // Continues for 4 seconds

motorSpeed(4,0);      // Sets all motors to 0% power

goFor(10);                   // Continues for 10 seconds

The figure above is the code that was used.

Lab 5 (2/21/2107)

 

Summary

The AEV was fully assembled in order for it to run on the track. The team did this by screwing on the L-shape arm and ensuring all the screws and nuts were tight because it was previously deconstructed. A code was written for the AEV to perform various actions on the track so they could observe how the AEV responded to the code. The code was written on the sketchbook program. The team then put the AEV on the desktop stands and waited for an instructional team member to see how the AEV responded to the code while sitting still. This was done so that the AEV would not fly off the track or crash while on the track. The AEV was placed on the track, the code was started in the arduino, and the AEV was observed to see how it responded to the code. This was done so the team could accurately fill out the concept screening scoresheet for the each AEV design. A concept scoring matrix and a concept screening score sheet was developed for the team design and the original designs. This was done to accurately see what AEV was the best overall design. The team completed the concept screening score sheet by looking at each design and seeing if it was better, worse, or the same as the reference AEV. The concept scoring matrix was completed by rating various aspects of the AEV on a scale from one to five, multiplying that number by the weighted percentage, and then totalling up the score. Making these scoresheets allowed the team to pick the best AEV and see what parts of the AEV were the best and the worst.

 

Results 

This lab dealt primarily with the development of concept scoring and concept screening scoresheets. A concept screening and scoring matrix was developed in order to determine a final design. The concept screening scoresheet produced a score for each design. The design was awarded a plus if the new design improved this area in comparison to the reference design, a minus if it made it worse, and a zero if it remained the same. Four designs were scored in comparison to the original AEV design.

 

Evan’s design produced the same results for covering curves, blockage, cost, environmental effects, and center of gravity as the reference design. This design improved the efficiency, but decreased the AEV’s durability. As seen in Figure 1, a net score of zero was produced for this design, and the team decided that this would not be utilized in future project endeavors. Cameron’s design increased the AEV’s ability to cover curves and the vehicle’s center of gravity, but decreased the affordability. This design remained constant in comparison to the original design in the areas of blockage, durability, environmental impacts, and efficiency. As depicted in Figure 1 this design obtained a net score of 1, and the team decided that this design will not be utilized throughout the remainder of the project. Alex’s design remained constant in the areas of corner coverage, blockage, durability, environmental impacts, and efficiency. The design improved the AEV’s center of gravity making it more balanced and stable, but added additional costs, decreasing the affordability of the design in comparison to the reference design. As shown in Figure 1 the design earned a net score of zero. The team decided that no further action would be taken with this design in future aspects of the project. Ahmed’s design decreased the AEV’s durability, cost, and efficiency. This design held constant in the areas of curve coverage, blockage, center of gravity, and environmental impacts. This design was awarded a net score of -3, and will also not be used as the final design

A concept screening scoresheet was also developed for the group design. This design allowed for the AEV to be more environmentally friendly, affordable, and durable. This design decreased the center of gravity of the vehicle, and the aspects of curve coverage, blockage, and efficiency. Overall, the group design produced the highest net score of 2, and will be the design that the team will move forward and develop throughout the entirety of the project.

 

Additionally, the team compiled a Concept Scoring Matrix for the reference AEV, Cameron’s design, and the team’s design. The team used the same success criteria as the concept screening scoresheet, which included covering curves, blockage, center of gravity, durability, cost, environmental aspects, and efficiency. The first design that was examined was the original AEV design. The reference AEV excelled in the area of blockage, in which it scored a three, this is important because this category had the most weight out of all the other criteria. The reference AEV scored a total of 2.55 as evident in Figure 2, and the team decided that no progress would be made on this design. Next, Cameron’s design was observed, which scored well in the areas of center of gravity and covering curves.  The design received an overall score of 3.1, and the team will not move forward with this design. Lastly, the team performed a Concept Scoring Matrix on the group design. As referenced in Figure 2 this vehicle design scored above average in the areas of center of gravity, durability, and the environmental impacts. This design scored a three in all other areas, for a total score of 3.35. This was the highest score out of all three designs, and is the reason that the team will be moving forward with this AEV blueprint for the remainder of this project.

 

The AEV responded very well when it was challenged with running on the track. At first, we forgot to reverse one of the motors because one of our motors is backwards on our respective design, but after we fixed that, the AEV ran very smoothly. The AEV did have a slight tilt to it when it was placed on the rail; however, it was very slight and had almost no effect on the AEV. The team decided to make some adjustments on the AEV. First, it was decided that the propellers would hang down from the AEV and that they would both pull the air to control the AEV. Next, it was decided that the arduino would go on the bottom and the battery holder would go on the top, so that way there would be more room on the AEV to transport materials.

 

 

The figure above depicts the concept screening scoresheet. This graph displays success criteria developed by the team which includes covering curves, blockage, center of gravity, durability, cost, environmental aspects, and efficiency. A score is given for each design and awarded a plus if the new design improves this area in comparison to the old design, a minus if it makes it worse, and a zero if it remains the same.

The figure above depicts the Concept Scoring Matrix, which describes the different success criteria using a weighted scale. Each criteria is rated on a scale of 1-5, and a weighted score is produced by multiplying the score by the weight. A total score was produced for each design. The reference design, Cameron’s design, and the group design were all rated using this method.

 

 

reverse(2);                                      // Make one of our motors going backwards

celerate(4,0,25,3);                        // Increases all motor from 0 to 25 power in 3 seconds

motorSpeed(4,25);                       // Runs all motors at 25 power

goFor(1);                                        // Continues for 1 second

motorSpeed(4,20);                      // Decreases all motors to 20 percent power

goFor(2);                                        // Does this for 2 seconds

reverse(4);                                     // Reverses all motors

motorSpeed(4,25);                      // Runs all motors at 25 percent power

goFor(2);                                        // Does this for 2 seconds

brake(4);                                        // Stops all motors

The figure above is the code that was used.

 

 

 

Team Meeting Notes

 

Date: 2-16-2017

Time: 5:00-6:00  pm

Members Present: Cameron, Alex, Evan

 

Topics Discussed: We discussed who should do which projects and parts on the progress report while incorporating and taking in consideration objectives and goals we needed to accomplish outside of the lab report including building the AEV.

Objective: Evenly distribute the work of the progress report along with setting dates they should be completed by.

To do/Action Items: Situation for past week, situation for next week, and weekly goals and schedule.

Decisions: The next meeting date was determined to be on 2/21.

 

Date: 2-21-2017

Time: 9:00-10:30  am

Members Present: Alex, Evan

 

Topics Discussed: What needs to be completed for the progress report as well.  We also discussed the website for our group and the agenda for the class concerning the next couple of weeks

Objective: Get up to pace on the website and finish the results charts so we can write about them.

To do/Action Items: Insert and comment all code used in the lab, finish the screening concept analysis table, write descriptions on each, format the progress report.

Decisions: Need to meet tonight to continue working and finish the progress report as well as discuss topics went over today in lab.

 

Date: 2-21-2017

Time: 3:45-5:00  am

Members Present: Cameron, Alex, Evan

 

Topics Discussed: The final sections that need to finished up including the backward looking situation and final touches on the results and analysis.

Objective: Can final turning in material completed.

To do/Action Items: Read over the entire report looking for errors made concerning past tense and spelling mistakes.

Decisions: Everything is finished and the lab is ready to be turned in.

 

Performance Test 2 (3/24/17)

Summary

Labs 9A-9C allowed the group to experiment on the pros and cons of two separate codes after testing them. During these labs the group centered its focus on creating a code that could complete the whole run. Focus was put on programming one code that would complete the given mission, then the team worked on developing a possible alternate code. During Lab 9A, trial and error while testing code was used to gather information to use while creating a final code. The team produced a code that created consistent results while accomplishing the tasks on the track. The objective of the second half of Lab 9B was to create a second run code for the AEV. The efficiency of the second code was compared to the first code to determine ways the code could be improved. This second code made it possible to understand how different lines of code and power used affected energy consumed and consistency.

Results

 

The team observed the AEV react to two different codes on the track. The AEV responded well to both codes; however, the second code was not tested on the track as much as the first, and the AEV messed up when passing through the gate. The AEV struggled to move when carrying the other cart back due to the lack of power. It successfully completed the course when running the first code, but was out of control at times. The AEV swung back and forth vigorously after going around the turns on the track. The team observed the pros and cons of each of these codes and will produce a code that will be the best of both codes in upcoming labs. The team will use the gliding without any power from the second code and the power from the second code to produce the best code.

 

The team developed two separate codes in order to optimize and maximize the efficiency of the AEV. The first code was developed by the team and was tested multiple times on the track successfully. The main difference in the second code was a decrease in the overall motor speed. As evident in Figure 2, the motor speed was decreased from 35 to 25 percent power. This increased the efficiency by moving slower and more consistent along the track. Another difference between the two codes was in regards to the section of the code in which the AEV traveled to pick up the other vehicle. The team adjusted the code so the AEV coasted towards the other vehicle as opposed to using another motor speed function as seen in Figure 1. This saved energy in the long run for the AEV because it was not using energy while gliding on the rail. While the second code would be more energy efficient, it code was not consistent and had not been tested as often as the first code. The team felt more confident in the first code’s ability to complete the assigned tasks. However, the team could implement the final part of the second code in order to have the AEV coast towards the other vehicle in a more controlled and efficient manner.  

 

The goals for next lab are to create a third code and graph the efficiency of all three code runs on the same plot. This will be accomplished using the MATLAB data taken from the AEV. The graph will then be separated into different phases and compared according to what code was being used at that time. This will be used to choose between what code to use for the final test.
As is evident in Table 1 the AEV traveled from the start to before the gate, stopped for 7 seconds, and continued through from the gate to before the caboose. After this the AEV traveled back to the gate again, and stopped once again at the gate for an additional 7 seconds. After this, the AEV traveled from the gate back to the start position and stopped.

 

Team Meeting Notes

Date: 4-3-2017

Time: 4-5  pm

Members Present: Evan Berry, Alex Savelieff

 

Topics Discussed: Proofreading and finalizing the progress report

Objective: Ensure all parts are present and up to the team’s standards

To do/Action Items: Read through the entire document and ensure there are no major issues

Decisions: The progress report will be checked and turned in on time

Performance Test 3 (4/10/17)

Summary

The week’s labs focused on the improvement and development of a more energy efficient code. This was done by implementing the brainstorming ideas from previous labs. For instance, the motorspeed throughout the code was lowered in order to decrease the energy consumption. Additionally, the third leg of the code removed the need for a motor speed function in order to stop the vehicle. Instead, the AEV coasted to the desired location instead of expending more energy on reversing the motor, making the vehicle more efficient. Another point of emphasis in this week’s lab was to make the AEV run on the track more consistently, as the team encountered issues having it stop regularly at the desired gates. This was done by testing several times on the track to determine the exact wheel counts necessary to complete all aspects set out by the MCR.       

Results

 

This lab dealt with fixing issues in the AEV code and the AEV itself, while making the AEV more energy efficient. The team first made the AEV glide more on the rails; moreover, making the AEV more energy efficient. The team also made the AEV slow down for two reasons; allowing the AEV to use less energy and getting the AEV under control at a lower speed so it was not shaking as much on the rail. The team came across some problems while completing this lab. One problem was that the AEV was shaking while traveling on the rail. The team fixed this by slowing the AEV down as stated before. Another problem that was encountered was that the AEV was not running consistently using the same code. This problem was overcome by tightening all the parts on the AEV and making the code more concise as well as assuring that all wheel count marks were accurate. The team arrived at these decisions by coming together and communicating. Each team member gave suggestions on how to improve the AEV and fix any problems, and the team decided on the best options. One problem that was not resolved was the AEV not connecting to the caboose via magnet. The team had many of the objectives as stated in the Mission Concept Review already completed. The team will continue to try to improve the energy efficiency of the AEV. Each member would come to the next class with at least one idea on how to make the AEV more energy efficient. They will be discussed and at least one idea will be decided on to implement in the AEV design. The team also needs to figure out how to connect the AEV to the caboose in a more consistent manner. This problem will be addressed at the next meeting.

Team Meeting Notes

The team did not meet at anytime to complete this lab. Parts were assigned via google docs and all parts were completed individually.

 

Lab 4 (2/14/17)

Summary

At the beginning of the lab, a program was developed that allowed the AEV to travel from the starting point to the gate. This skill will be useful when programming the final project because the AEV will have to travel certain distances. Before the AEV was tested, the team confirmed that the AEV was balanced on the track. This was to ensure the AEV was stable before it was put above the heads of our classmates. After the code was completed, it was uploaded to the arduino and tested multiple times on the rail in order to ensure that the AEV stopped abruptly once it passed the gate by using the “reverse” and “motor speed” commands. The team collected the data from the successful run. The AEV recorded data every 60 milliseconds over a total of approximately 15 seconds. The team transported the data to MATLAB by using the sketchbook program. The code “aevDATARecorder” included in the sketchbook, helped the team in extracting the data collected from the arduino while the AEV was running. In MATLAB, the units of time was converted from milliseconds to seconds, check this EEPROM current(ADC counts) to current(amps), EEPROM voltage to voltage, wheel counts accumulated to meters, and finally, wheel counts recorded by reflectance sensors to AEV position(meters from starting point). These conversions were made to transfer the information in the arduino, which is in binary measurements to standard units the team could use to calculate the total energy (Joules) from the incremental energy (Joules) and input power (watts) using voltage and current. After the data was collected and converted, a plot of power vs time, power vs distance, energy vs time, and energy vs distance was made to visualize the data of the AEV run and determine where and when the AEV consumed the most power and energy during the run. These plots was developed on MATLAB using the plot features commands and can be seen in the MATLAB Code in the Appendix. The power vs time graph was divided into six different phases according to major changes in power inputs. Total energy was calculated by adding all the incremental energies together. This data is represented in Table 2 which contains the time, distance, phase, incremental energy, total energy, and arduino code that was running. The second plot was a power vs time graph and was made in the second part of the lab used the MATLAB graphical user interface (GUI). The arduino data was downloaded into “AEV_Analysis_tool.mlappinstall” which created the plot automatically. From there, the computer completed the analysis calculations. 

 

Results

The test data for power vs time was divided into six phases based on major changes in power. The phase division can be seen in Figure 1 on the power vs time plot along with Table 2 which displays the arduino code, time, distance, incremental energy and running total energy at each phase. The first phase ran under the “reverse(2)” and “motorSpeed(4,35)” code from 0 to 0.36 seconds and took up 3.8155 Joules of energy.  The second phase ran under the “goToAbsolutePosition(450)” code from 0.36 to 8.5220 seconds with an incremental energy of 78.3791 Joules which brought the total energy used up to 82.1946 Joules. The third phase coincided with the “reverse(4)” command and spanned from 8.5220 to 8.9420 seconds which took up 4.8179 Joules and brought the running total energy to 87.0125 Joules. The fifth phase ran under the “break(4)” command and lasted from 11.5820 to 12 seconds. This phase took up 1.8690 Joules and added to the total energy to make it 114.5886 Joules.  The sixth and last phase was taken after the AEV braked and stopped running between the times of 12 to 14.7020 seconds with a phase of 0.4407 Joules to make the total energy through the entire run to be 115.0293 Joules. When the AEV first gets started in phase 1, there is a very short spike in power supplied. This is due to the propellers moving from rest. Phase 2 ran for the longest amount of time and took up the most amount of energy.  This phase coincided with the AEV traveling the length of the track to get to the gate. It is expected that this phase took up the most energy because it traveled for the most amount of time. There is a spike in the amount of power used in phase 3 that is a result of reversing the propellers while going full speed.  The propeller motors have to fully come to a stop, and then reverse the direction they are going, taking up a lot of power. Once the propellers were reversed, the power remained consistent with the results of phase 2. As soon as the AEV reaches phase 5 at approximately 12 seconds, there is a dramatic decrease in the power as the command breaks. This is followed by phase 6 as the power decreases to zero. Figure 2, 3, 4, 5, and 6 show the AEV Test Data of power vs time, power vs distance, energy vs time, energy vs distance and the computer calculated power vs time respectively.

In Figure 1, the power vs time plot located in the appendix gives a physical representation of the power used during the test run. This plot aided in the team’s coding strategy in many facets. The plot showed multiple different phases of the AEV and the amount of power during every phase. The graph showed the time in seconds (x-axis) being plotted against power in watts (y-axis). Each phase is either oscillating, increasing or decreasing. The results of each phase can be helpful in reading the amount of power used in different tested programing codes, this would better the AEV performance in future labs by giving the team information to make changes that will better the AEV design. Figure 2 was the same plot as Figure 1 but without the phases. Figure 2 is the power vs distance which has similar results to Figure 1 and Figure 2 because the only thing changing in the plot is distance for time, which has similar incremental values of power. In Figure 4, Energy vs Time is being graphed, the plot helped the team notice that as time increased so did energy, which means they have a directly related correlation. In Figure 5, the energy vs distance plot showed that as the AEV distance increases, lower amount of energy is needed for the AEV to keep moving.  Figure 6 is the same plot as Figure 1 and Figure 2 but it was made by the MATLAB Application and not the MATLAB program like all the other graphs. The plots made aided the team in writing a better program and design because the team tested for the most efficient Arduino code that will be achieved by analyzing the plot that corresponds to the program written by the team and adjusting the code depending on an increase or decrease of power or energy input.

Looking ahead, Lab 05a and Lab 05b deals mainly with screening and scoring of the design concepts. In this lab the team will code a program that will allow the AEV to travel on a straight path on the track. Additionally, the team will develop a screening and scoring of the AEV design.  All the responsibilities for the labs are located in the appendix.

Team Meeting Notes

 

Date: 2-6-2017

Time: 6:00-7:50  pm

Members Present: Evan Berry, Alex Savelieff, Cameron Eckles, Ahmed Negnm

 

Topics Discussed: Distributing parts of the lab report and assigned specific roles to everyone.

Objective: Get the agenda set for the lab.

To do/Action Items: Split up each section between each other.  Plan the next meeting and what should be done by then.

Decisions: Evan is going to complete the results and analysis along with keep the team meeting notes and proofreading the final paper.  Ahmed is doing the present situation, weekly schedule, and question 2. Alex is going to do the future situation and question 1. Cameron is going to complete the takeaways, weekly goals, and work on question 1 with Alex.

 

Date: 2-9-2017

Time: 9:30-11:00  pm

Members Present: Evan Berry, Alex Savelieff, Cameron Eckles

 

Topics Discussed: What we have completed so far on the lab and what we still need to complete.

Objective: Start the lab and get some of the parts completed.

To do/Action Items: Plan the next meeting and what should be done by then. Continue to work on our parts of the lab.

Decisions: We will meet Saturday morning to complete most to all of the report and not worry about it during the week.

 

Date: 2-11-2017

Time: 10:00-11:30  am

Members Present: Evan Berry, Alex Savelieff, Ahmed Negnm

 

Topics Discussed: What parts still need to be completed.

Objective: Finish most to all parts of the report so we don’t have to worry about it over the week

To do/Action Items: Finish up the calculations along with all of the parts we each have to do.

Decisions: One more meeting needs to be in place to go over everything. We need it done by Monday to take it to the GTA and get it checked over.

 

Date: 2-14-2017

Time: 4:00-5:00  pm

Members Present: Evan Berry, Alex Savelieff

 

Topics Discussed: Square away loose ends of the project work on formatting

Objective: Proofread and finish lab

To do/Action Items: Make sure all aspects of the lab are present, complete, and valid

Decisions: Turn in lab and plan next meeting

 

Lab 3 (2/7/17)

Summary

This lab focused mainly on aspects of the creative thinking process. The lab emphasized two techniques for creative design thinking which included generating a useful idea and effectively communicating it to others. The team became familiar with obstacles to creativity which included fear of criticism, lack of confidence, and negative stress. These obstacles were important to understand as they were taken out of the brainstorming process to make for a creative, safe environment. The team individually brainstormed unique and inventive ideas for the AEV which included features that could aid the AEV’s ability to complete the scenario as well as provide aesthetic aspects. Implementing these new ideas, individual AEV designs were created by each team member using orthographic paper and proper dimensions. This was done to give the members experience in creating orthogonal drawings from real world objects. The team then brainstormed together and the remaining time was spent combining ideas and individual drawings into one master design. This was done so the AEV would have a final design all members agreed upon as well as giving the group a chance to share ideas and collaborate on a final design. This design was made as an orthographic drawing, followed all design guidelines, had overall dimensions, scale, estimated weight, and bill of materials.

Results

The individual team members had similar designs that resembled the original AEV design for the most part. However, when the team brainstormed together, the final design incorporated aspects from each design that made for a creative and unique final drawing. This made for a sketch that is easily differentiated from its counterparts. These changes were implemented in order to cut down weight, make for a more aerodynamic vehicle, and to add aesthetically pleasing aspects to the design.

The team first decided that one propeller on the front and back of the AEV should be implemented into the new design. This makes for a combination of the pull and push design, in which the the propeller in the front is pulling the air and the propeller in the back is pushing the air. This decision was made in order to distribute the weight more evenly between the front and the back of the AEV. The team also put two trapezoids for wings on the side of the AEV. This allowed for a more aerodynamic AEV that would glide through the air and reduce drag. It was also decided that this AEV would include aesthetic aspects that would incorporate aspects of Ohio State. The team added two buckeye stickers on the wings along with an Ohio State cardboard cutout on the front. The use of cardboard instead of a heavier material allows the AEV to maintain its lightweight features. The cardboard is also in a triangle shape so that it cuts through the air better. The team also decided to take off the angle bracket that was located in the front of the sample AEV. This bracket did not serve a purpose and cut down more weight from the vehicle. The sample final AEV with most of the features we have incorporated is shown in Figure 6. All of these changes were made to help better assist the AEV in completing the scenario in the MCR.

In Figure 1: Propellers Down AEV Design, the wings on the sides were pointed downward along with the wings. This design was much different than the original design as the force created by the propellers is pointed downward and backwards. The force therefore was pushing the AEV upward as well as forward which took friction off the wheels and created lift using the wings. The wings were also pointed downward which created a lift force on the AEV and took more friction off the wheels. Less friction on the wheels would allow the AEV to travel at higher speeds and use less battery power. The design used very minimal materials as seen on the bill of materials in Table 1. Most of the materials were reused from the original AEV design. Brackets and a small piece of plastic are the only new materials needed to complete the new design.

In Figure 2 the design consisted of the 2.5 by 7.5 rectangular base, along with two trapezoids on either side at a slanted position. The two trapezoids were connected at the back of the AEV, with the propellers attached to each one. The propellers were put at the back of the AEV which decreased drag from the “wings” (trapezoids) of the AEV on either side. This AEV design included the L-shape arm and the wheels implemented similar to the original AEV design. Additionally, this drawing included a rounded dome at the front of the AEV, which worked to make the vehicle more aerodynamic and aesthetically pleasing. This addition allowed air to move up over the base of the AEV, reducing drag, and allowing the vehicle to move faster and more efficient. This dome would be made utilizing 3-D printing or would be purchased at a store in order to be implemented into the design. No other items would need to be printed or bought in order to complete the remainder of the project, as the rest of the materials were already present in the AEV kit. The team utilized a brainstorming techniques by asking questions about how far the design of the AEV could be taken. Asking these questions effectively helped the team gather information that aided in the design, and allowed the team to add more creativity and individuality to the design process.

Figure 3: Arrow Head design was similar to the original AEV design, but with some different features. The base is a 7.5” x 2.5” plastic sheet with two trapezoidal wings connected toward the back of the AEV making them wings. The motors and propellers are under the wings. There was an L shaped arm that is perpendicular to the base that will hold the AEV to the rail. The change that was made is that there is a small triangle connected to the front of the AEV to make it more aerodynamic. This would allow the AEV to glide through the air better and complete the scenario more efficiently. This triangle would be made out of cardboard so that it would not weigh much at all. The team utilized this triangle shape on the final AEV design by making an Ohio State logo that is triangular shaped at the front. This was the only thing that the team took from this design.

Referring to Figure 4, the AEV was built to go faster and withstand damage while it maintained a lightweight design. At first it was challenging to come up with an original design, but using the brainstorming technique it allowed for a more creative design. The design from the top orthographic view has a triangular shape with 6’’x9’’ and a rectangle that is 3’’x2’’ at the bottom with wings attached to the rectangle with a 6’’ distance between them to represent the propellers. The wings are built far apart from one another in order to make the AEV capable of pushing as much air behind, which allowed the AEV to move better in the air and increase its speed capability on lower battery power. Each individual sketch was done with materials that make the AEV as efficient as possible. The less materials used made for a more efficient AEV, due to this, this design does not include many outside materials. Most of the materials are used from the original AEV design. Instead of using the same exact shape of the plastic material though, it would be more cost effective and efficient to cut the thickness of plastic material in half; allowing for an AEV with a lighter weight. Cardboard would be used to build the bottom rectangle to make it even more lightweight.

Team Meeting Notes

 

Date: 2-6-2017

Time: 6:00-7:50  pm

Members Present: Evan Berry, Alex Savelieff, Cameron Eckles, Ahmed Negnm

 

Topics Discussed: Distributing parts of the lab report.

Objective: Make sure we can finish all parts of the report by tomorrow.

To do/Action Items: Split up each section between each other.  Plan for all the parts to be completed by tonight and read over tomorrow morning.

Decisions: Turn in the lab report tomorrow night before it is due. Meet then to finish everything.

 

Date: 2-6-2017

Time: 7:00-8:00  pm

Members Present: Evan Berry, Alex Savelieff, Cameron Eckles

 

Topics Discussed:

Finalizing all aspects of the design and proofreading all lab material

Objective: Ensure that all parts are present and accurate.

To do/Action Items: Have each member to a complete readthrough of the lab and make sure there ar e no glaring errors

Decisions: Turn in the lab

 

Lab 2 (1/31/17)

Summary

Lab 02 placed an emphasis on the external sensor hardware components. The team became familiar with troubleshooting techniques and the program functions calls related to the external sensors with the AEV control. This was done by programming a line of code that made the AEV travel a certain distance on the track and then reverse. Being familiar with programming will be useful later in the project when the AEV will be required to run multiple tasks. The team constructed the base of the AEV by referencing the 3D model. The external sensors were then installed along with the wheels. This was done by referencing  images and examples in the Lab Manual and 3D model and replicating the designs. The construction of the AEV is required for the mechanism to run on the track. Using the command “reflectanceSensorTest” the team was able to observe how the number of marks from the serial monitor increased or decreased depending on which direction the wheel was turned. This was done in the sketchbook program. This is relevant because converting from tics to distance through a simple math conversion helped the team determine how far the AEV traveled. This information will be utilized when the AEV has to line up with specific points along the track. The final part of the lab required additional testing of the reflective sensors by entering a set of commands. This testing was done the same way as before – using the sketchbook folder and programming a set of commands that use the “reflectanceSensorTest” command line. This was done to ensure the sensors were working correctly. Due to time constraints the team was not able to complete this portion. Time will be alloted from the next lab to accomplish these tasks. The team collected data that measured current, thrust scale reading, RPM, and the arduino power setting. This was accomplished by one group member going to collect data from the wind tunnel testing area. This is useful because this data was utilized in calculations that are relevant for future aspects of this project.

 

Results

To collect accurate data, one member of the team observed a test of two different propeller configurations at various arduino power settings. The team member observed the RPM of the Puller 3030 started off higher than Puller 2510, but after 15% arduino power the Puller 2510 had a much higher RPM. At 60% arduino power, the Puller 3030 had an RPM of 12596 and the Puller 2510 had an RPM of 20248. The propellers were only tested up to 60% arduino power which can be seen in Table 1 and Table 2 located below. Although the RPM of the Puller 2510 was much higher, the Puller 3030 had a significantly much higher thrust scale reading throughout the whole experiment. At 60% arduino power, the Puller 3030 had a thrust scale reading of over 300 grams and the Puller 2510 had a thrust scale reading of approximately 220 grams at the same power setting. The Puller 3030 had a higher current after 10% arduino power. At 60% arduino power, the current of the Puller 3030 read at 1.86 amps and the Puller 2510 read at 0.57 amps.

The team then proceeded to make a graph of Propulsion Efficiency vs Propeller Advance Ratio. he graphs are depicted from right to left because as power increases, advanced ratio decreases. Looking at Figure 7, the Puller 3030 started with an efficiency of approximately 35%, rose to over 50%, and then steadily decreased to 15% efficiency at the highest power percentage. Considering Figure 6, the efficiency of Puller 2510 started at 0% and steadily rose to 17% by the highest power percentage. The Puller 3030 tested out to be the best propeller to use because it had a higher propulsion efficiency through most of the experiment. When evaluating the best propellor, it was best to go off the efficiency of the respective propeller. Considering these points, the Puller 3030 was the best propeller configuration to use on the AEV.

The team used the 3-Dimensional model of the AEV to assist them in building the sample AEV. The AEV was built exactly as pictured in the online model. The team first tested the code while holding the AEV to make sure the code was working properly. The team rolled the wheels with their hands to make sure that the code counted the ‘tic’ marks correctly. The code correctly counted the number of ‘tics’ and responded correctly. When the team first put the AEV on the track, the propellers thrusted the AEV in the wrong direction. After the team reversed the motors, the AEV moved in the correct direction, but the code did not count the number of ‘tic’ marks. The team noticed that the AEV struggled to move with only 25% power to the motors. The team concluded that the AEV’s motors must be above 25% power to move steadily. Due to time constraints, the team was unable to test different powers with the motors. The team also was unable to fix the problem with counting the number of tics. The team will use time in lab three to fix these problems.

The AEV stayed on the track and moved from the start gate to the finish gate as directed by the code. The constructed AEV made it to the desired gate, however it did not stop when the code had indicated. The AEV continued through the desired stopping point. The team utilized troubleshooting techniques the problem and concurred that the AEV did not stop for two possible reasons. First, an error in calculating the correct number of ‘tic’ marks needed to run could have caused the AEV to travel more than sixteen feet.  Additionally, the team used a reverse command to get the propellers to turn in the right direction. In doing this, it reversed the sensors input so that it was increasing instead of decreasing. After further inspection of the AEV behavior on the track it was observed that the vehicle travelled at a slower speed than required because the motors were not running at full power output.  The AEV would occasionally stop at points on the track, which required a push from a team member. The team members tested the AEV at 25%, which is what accounted for the slower speed of the vehicle. The team did not have time to test different speeds due to time constraints, and will allot time next lab to correct this issue.   

After reviewing and discussing the propeller results, the Puller 3030 was determined to be the best propeller configuration. When evaluating the graphs of the propulsion efficiency, the graphs are depicted from right to left because as power increases, advanced ratio decreases. Looking at Figure 7, the Puller 3030 started with an efficiency of approximately 35%, rose to over 50%, and then steadily decreased to 15% efficiency at the highest power percentage. Considering Figure 6, the efficiency of Puller 2510 started at 0% and steadily rose to 17% by the highest power percentage. The Puller 3030 tested out to be the best considering it had a higher propulsion efficiency  throughout most of the experiment. Considering these points, the Puller 3030 was the best propeller configuration to use on the AEV.

After putting the AEV on track the team will utilize the knowledge gained from analyzing the AEV on the track to construct the code for the final project. The group tested out a specific motor power percentage and how the power percentage affected the propellers that controlled the AEV. The team also noticed the design of the AEV cannot be too wide or it will be problematic due to clearance dimensions of the track.

Team Meeting Notes

 

Date: 1-22-2017

Time: 8:00-9:15  pm

Members Present: Evan Berry, Alex Savelieff, Cameron Eckles

 

Topics Discussed: We discussed who should do which projects and parts on the progress report.

Objective: Evenly distribute the work of the progress report along with setting dates they should be completed by.

To do/Action Items: Divide all the parts and communicate with team members not present to the meeting what portions of the report they are accountable for.

Decisions: The entire progress report should be completed by 1/29 and a meeting will take place on that date.

 

Date: 2-2-2017

Time: 10:00-12:30 pm

Members Present: Evan Berry, Alex Savelieff, Cameron Eckles

 

Topics Discussed: We discussed what needs to be done to turn in a finished product.

Objective: Finish all parts not completed so far and turn in the progress report.

To do/Action Items: Results and analysis; questions 1,2,3; proofread the entire report.

Decisions: All the individual components will be completed and in the lab report by tonight, the lab report will be submitted tomorrow morning and the paper copy will be used printed out for class tomorrow.

 

Date: 2-3-2017

Time: 8:30-10:00 pm

Members Present: Evan Berry, Alex Savelieff, Cameron Eckles, Ahmed Negm

Objective: Make sure everything on the progress report is completed and finalized along with no spelling errors and grammar mistakes.

To do/Action Items: Proofread report and turn in the lab, along with printing out a hard copy for class.

Decisions: The lab is ready to turn in with no mistakes or parts missing.

Topics Discussed: Proofread the lab and format all parts into the correct section of the paper.

 

Lab 1 (1/24/17)

Summary

Throughout Lab 01, which dealt with Arduino programming basics, the team became familiar with the automatic control system hardware components. They went through and identified each part in the kit; marking them off on the “AEV Kit Checklist” when each part was accounted for. This ensured  all parts needed for the project were provided and that each team member knew the name and function of each part. This will aid the team in future projects, making it easier to understand the lab readings, and better understand the project. In addition to the inventory check, basic function calls were used to program a set of instructions and upload the code on the Arduino using the sketchbook program. This was done by opening up the sketchbook program, and putting the code under the “01_myCode” tab. The basic function calls utilized included “celerate”, “motorSpeed”, “goFor”, “brake”, and “reverse”. The team split up the work between the group and each member coded a portion of the program before connecting the Arduino to the computer and uploading the final code. This provided experience with basic programming and connection skills that will be used throughout the project to operate and test other controls. The team also mounted the curved propellers firmly to the motors with the dull side away from the motor. This was done to observe how the code worked with the propellers and eventually how it will move the AEV later in the project. Lab 01 left the team members with an understanding of the functions of the sketchbook program and how a program can be uploaded to the Arduino.

 

Results

An arduino code attempted to test and control the AEV propellor system. One of the motors did not work; this was an internal error that was difficult to resolve. One of the motors responded to the code while the other stopped and started very quickly. The motor must be replaced for the system to work correctly. This lab error was useful as any internal errors that occur will be quickly identified. Lab setup and testing takes a large amount of the lab period and efficient work was required to finish the lab on time. The lab was not completely finished in the period provided and the second optional part of the lab, Scenario 2, was not attempted. Better time management and allocation of lab responsibilities are necessary in future labs. No quantitative results were taken from the lab but many qualitative results were recorded from the system failure.

During the first test, the propellers were unable to run. After an examination of the motor, the propellers were determined to be touching the motor and creating unwanted friction – stopping the propellers from rotate. After testing a second time, it was determined that the friction against the wall was not the problem. The lab group attempted to troubleshoot the problem, checking each connection. With no success, the TA was asked to check over the configuration for any obvious errors made during the setup. An error was not discovered and the group was referred to the GTA office hours. At the office hours, another unsuccessful attempt was made to get the motors to run, the problem was postponed to the next lab period. The group will attempt a third time along with more troubleshooting to resolve the problem.

The commands used to make the AEV function have limitations associated with them. When using the “brake(m)” command the AEV does not stop immediately. The function does not brake the AEV system, but rather cuts the power from the motor. Additionally, the track itself was a restriction as the AEV can only go as far as the track allows. This will need to be taken in consideration when programming the tasks that will need to be completed by the AEV – it cannot be programmed to go a further distance than the track will be capable of carrying it.

The team wasn’t able to finish the first scenario and as a result could not start on the second scenario due to multiple errors. The first significant error was connecting the wrong COM port in the program, which wasted time trying to figure out why the program did not connect to the Arduino. Another error that was made by the team was mounting the propellers too far down the shaft creating friction. The second Scenario was  to test out and get familiar with more sketchbook commands, including running both motors at the same time with different acceleration.

The team had trouble getting started during the lab experiment as seen in the errors made. The TA’s were needed often throughout the period to accomplish simple tasks. The lab group as a whole needs to read the laboratory manual thoroughly before the experiment for it to run more smoothly and efficiently in the future.

Team Meeting Notes

 

Date: 1-22-2017

Time: 8:00-9:15  pm

Members Present: Evan Berry and Alex Savelieff

 

Topics Discussed: We discussed who should do which projects and parts on the progress report while incorporating and taking in consideration objectives and goals we needed to accomplish outside of the lab report including building the AEV.

Objective: Evenly distribute the work of the progress report along with setting dates they should be completed by.

To do/Action Items: Situation for past week, situation for next week, and weekly goals and schedule.

Decisions: The next meeting date was determined to be on 1/23.

 

Date: 1-23-2017

Time: 6:30-9:00  pm

Members Present: Evan Berry and Ahmed Negn

 

Topics Discussed: Possibly setting up a general meeting time every Sunday that all members will attend if progress report is not completely finished.

Objective: Complete all parts of the progress report assigned to Evan and Ahmed.  Work together to figure out what should and should not be included on the takeaways and weekly goals.

To do/Action Items: Takeaways, next week schedule, situation.

Decisions: Create two mandatory meetings every week all group members attend.  One on wednesdays to plan the progress report completion and one on sunday to create the final copy of the report.

 

Date: 1-24-2017

Time: 9:30-10:30  am

Members Present: Evan Berry and Alex Savelieff

 

Topics Discussed: What changes need to be made to the progress report before we can submit it as a final copy.

Objective: Turn in final progress report and print out hard copy

To do/Action Items: Proofread entire report. Correct all errors including incorrect tense and grammar mistakes.

Decisions: The progress report is complete and ready to be turned in