In this lab, the team did further testing on the final developed code, and observed the energy efficiency over multiple tests. One complication of this lab were the data results received regarding the efficiency figures. The power output ranged no less than 300 and no more than 350, which are high numbers in terms of mass to power output ratio. While team F continues to work on adding final commands to the working code, the power efficiency is proving to be a difficult challenge. This issue is being overcome with less propellor work over the same period of time. The team is changing the code to promote more “gliding” of the AEV when it breaks, which decreases the amount of power needed to quickly and shortly reverse the AEV in order to stop it. Another issue originates from inconsistent AEV performance on the track during testing. After two to three tests, the AEV begins to fall short in distance and speed, and changing the battery to satisfy energy needed to run the AEV also tends to be met with over/underestimates in absolute position lengths in the code and the overall speeds of the AEV when reversing and going straight. The team is working on obtaining data on the voltage of the battery in use, and seeing how it changes over the course of the lab period to determine the true source of the error before final testing.

In order to follow the MCR objectives while having the most efficient vehicle, the team plans to make progress with the current lab setup; Testing the code and troubleshooting based on data received through the arduino. In terms of the physical aspect of the AEV, the team has decided to maintain the current prototype as the final model. As discussed in the previous lab, the team was working on the final code independent of monitoring the energy efficiency. The overall main goal for the team was to develop a code that meets all of the criteria given for final testing. Now that a working code has been developed, the team used this lab to not only tweak the code to compensate for any small errors in timing or speed, but have also used the lab time to now improve the efficiency figures produced by the AEV. While the team is observing similar efficiency levels as past labs, finishing the final code allows them to devote more attention to decreasing the overall power output. Regardless of the ultimate outcome of the power efficiency troubleshooting, the working code will be tested next week.

The team was able to further develop a process to make quick changes to the code in order to move closer to the final test/run. Other takeaways regarding the code included being able to see relationships between the motor speeds and the power output, and how the team could potentially decrease the output and promote a higher energy efficiency. This takeaway, while beneficial to the team’s overall performance, has been difficult to implement in the physical AEV model due to energy it takes for the AEV to carry the R2 unit back to the original position. The team has also overall been able to maintain a strong system of delegation seen in the first stages of the lab, working independently while still being able to come together with our ideas and conclusions and continue to develop a cohesive AEV product.

In Lab 9, Team F utilized trial and error to discover which combinations of codes and physical designs will provided the most energy efficient option for the AEV. Mainly focusing on the functioning code, the team observed how the energy output and overall propeller efficiency changed with different combinations of code. While the team was able to find a clear balance of push and pull with the propellers to produce the best efficiency, there were technical issues with the performance of the AEV with the code provided. The team spent a majority of the lab time doing small scale troubleshooting to develop a code that mirrored the final criteria of the lab (stopping at the gate, picking up the R2D2, pausing at the right times, etc.). This aspect of the lab came unexpectedly to the team, as the code created in the previous lab ran according to the final code criteria effectively. The team inspected the AEV and code, comparing it to any observations in the last lab in attempts to identify where the inconsistencies may have originated. No clear conclusions were made, though the team expects the code made in Lab 10 to run identically in future labs.

Differences in the code can be seen in how the arduino stops on the track. The team has chosen two methods to stop the AEV on the track. Either entering a brake command into the code prior to approaching the gate to account for coasting on the track, or making the motors reverse when the AEV gets to the gate to eliminate coasting and create a quicker brake time. The code that causes the motors to reverse is preferred because it gives the team more control over how and where the AEV stops on the track, however, it is less efficient than simply letting the AEV coast. Goals for the next lab are focused on making the Arduino perform according to the criteria of the MCR. All tests on efficiency and changes to the overall body of the AEV are generally concluded, so insuring the AEV runs perfectly is the main priority. Team F has, however, seen a constant increase in efficiency in the AEV as changes are made, and plan to continue to build upon these improvements until the final test/run, even though this may not be the main focus of these final labs. Currently, aspects that have increased efficiency are the placement of the propellers on opposite sides to promote the “push” and “pull” system, centralizing the weight of the arduino and battery, and configuring the propellers on vertical segments below the body of the AEV which has increased aerodynamics and consequently the efficiency as well. The team is completing a full circuit on the track by breaking the code into parts. The team is using comments in the code to break it down, and once one section performs sufficiently on the track, the team moves onto the next section of code. Essentially, each part of the track (performance before, during, and after the gate) will be performed in pieces of the code and will run accordingly.

Takeaways in terms of the AEV body originated from the positioning of the propellers. The team has made final decisions on the size/amount of material being used for the AEV body, however positioning of external parts are still being discussed. There was still a slight lean around the corners, and the team which will also become a factor of re-positioning external parts and testing to try and eliminate these errors. All coding takeaways can be seen in the ability for the team to quickly change the power output and absolute position in efforts to fill the criteria of the MCR for the final code.

This past week, team F has been gathering information to improve the current AEV design. Two top priorities for the team at this moment are aerodynamics and weight distribution. The code for the AEV is currently being developed at a satisfactory pace, so focusing on the efficiency of the design has occupied much of the lab time. These two priorities have been specifically chosen due to their degree of effect on the AEV performance. It was discovered that, with the addition of the new propellers, changes needed to be made to adapt to the speed in favor of ease of travel around the track. Since giving the design report presentation last Friday, the team has been taking Chris’ questions and advice into account for further testing and modification of the system. Providing quantitative evidence to support the claims of improved speed due to the new propellers and “diamond shaped” design is one goal that the team is moving towards producing in the near future. Anticipating the extra weight of the R2D2 apparatus is the driving factor for weight distribution of the individual AEV model. Without the R2D2, the AEV is observed to be bottom heavy, leaning outwards when making turns on the track. Therefore, moving the weight closer to the center/side of the AEV that faces the inside of the track is a modification that the team has implemented on the design. The team has also begun to make decisions on 3-D designs and materials that could potentially improve the AEV’s track performance. After taking notes and discussing the progress of other groups seen during the presentation lab day, Team F is hoping to develop a model of the AEV on Solidworks to give another perspective of the model, and allow the team to get a better picture of new potential designs and modifications.

During Lab 05, the team was able to examine the AEV designs based on its performance on the track. Using the screen and score decision charts, the team was able to select key features of the final AEV design, and prioritize what aspects of the AEV need to be agreed upon (cost, materials, weight, etc.) before their deadlines. During testing, the team ran a preliminary code created to travel a predetermined length of the track to the gate, pick up the R2D2, and return to the original position. The AEV ran smoothly on the track with the scenario code. When the code was activated, the AEV ran down the track without leaning to a particular side, even when making turns. It came to a smooth stop at the green gate and reversed immediately, returning to the starting point without any issue. The AEV stopped at the green gate approximately half a foot farther on the first run when compared to the second. Based on the performance of the sample AEV during the test, the team was able to make further progress on the screening and scoring tables.

Analyzing the screening and scoring sheets, the team favored all designs in terms of durability and maintenance mostly due to them being made by the same materials. Lauren’s design stood out for it’s projected balance and center-of-gravity which are key aspects of the AEV structure and performance. These ratings can be seen on the chart based on their numerical score from 1-5, 1 being poor and 5 being satisfactory. The limitations of the designs lied in blockage and environmental effect. Because each design has essentially the same parts, their configurations were hard to improve in terms of how the figures block other parts of the AEV.

The team was able to learn the importance of screening and scoring sheets to outline the future progress of the project. The tables made helped determine several final decisions on the AEV design, and also allowed the team to decide which aspects of the project were more important to finalize than others. The team is becoming more comfortable troubleshooting the code when setting up the Arduino, and altering the code to fit the criteria of the final code. In terms of track testing, the team was able to run the AEV on an Arduino code similar to that of the final project code, and got the opportunity to test with the R2D2 and monitor any changes necessary to the speed of the AEV to facilitate the extra weight.

Lab 04 was split up into two parts: collecting performance data from the AEV, and inputting the raw data into a MATLAB generated graph. For the first part of the lab, the team took on the task of getting the AEV to not only run on the track, but perform at different speeds and distances. While running, the Arduino collects data on the time, velocity, position, marks, and current of the trip around the track. The team then used a MATLAB data recording program to upload the information found and categorize it into a coherent data chart. The values found are based on units of measurement identifiable by the Arduino system, however, the team must use equations given in the lab manual to convert these values to ones easily applicable to the lab analysis and discussion.  

The second part of this lab consisted of developing these values into graphs through MATLAB to determine a visible trend in the data. The plot of the graphs communicated that the team’s coding strategy has proven effective and will be further implemented in future labs. These graphs and their analyses can be found in Appendix C (Figures 1-4). The team will need to complete a plethora of activities prior to the completion of the AEV, but is currently focused on the effectiveness of the code at hand.

The team was able to take away more understanding of code in terms of distance traveled and power used. Based on recorded data and visual observations, the team will also be able to further develop a final draft of the AEV design. In terms of data evaluation, the team is better equipped to find conclusions on how to alter the project based on numerical data and charts which provide a better idea of why and how we should change the code/structure. Additionally, it was realized that the data collection program may not be entirely  accurate, being that the code was designed to run the AEV on 40% power for the first two seconds but was reported that it dropped after approximately .25 second.

During Lab 03: Creative Design Thinking, Team F was able to take time conceptualizing the physical aspects of the AEV. At the beginning of the lab, the team used the analysis of creativity and innovation in the lab manual to outline discussion and research regarding the aesthetics of our AEV. Broken up into time frames based on the manual, the first 10 minutes were spent doing independent brainstorming with concept sketches based on design considerations given. Each member researched aerodynamics and properties of materials that could be used in our model. During the next 20 minutes, the team came together with individual orthographic sketches and compared aspects of each drawing. The main focus of each drawing was aerodynamics. The general outline sketch consisted of a pointed edge at the front of the AEV to help avoid air drag, and the Arduino component was situated within the structure for each sketch. Another integral component that was decided upon was the positioning of propellers on both sides of the AEV, which will aid in making opposite directions of travel more efficient on the track. A few more foundational decisions were made about preliminary aspects of our formal AEV design, and ideas surrounding 3-D parts were considered. These sketches can be found in Appendices C and D. The main materials for each design consists of plastic building parts provided in the original AEV kit, and also footnotes the use of 3-D printer filament for extra parts needed from the design. These materials were chosen based on consideration of AEV weight and the ability for the team to easily obtain with little to no cost. In terms of weight consideration, it was unanimously decided that the weight of the AEV should be as minimal as possible in order to cut the amount of power used by the motors for movement. Weight distribution was also a factor in preliminary design in order to avoid the AEV from flying off of the track when traveling around the curves.

During the other half of the lab, the team continued testing the AEV and working off of manual instructions for Lab 02. In light of  recording all events that occurred during this lab period, it is important to document that wires of the AEV malfunctioned and began to release smoke upon connection to the LiPo battery. All operations were immediately cancelled, and a new wiring system was installed into the Arduino system. Subsequent to the malfunction, the team worked to finish all criterion listed in the manual for producing an Arduino code, and began physical testing on the track. Due to lack of time, the team was only able to test the AEV on the track once, a test that proved successful for motor performance and unsuccessful for AEV movement. It was concluded through observation that the motor power was not high enough to effectively move the system, and the team decided to alter the code for a higher power value in future track testing.

A main takeaway regarding the functionality of our AEV is the importance of following the Mission Concept Review in the lab manual. It outlines that the AEV should adhere to the concepts of  energy management, operational efficiency and operational consistency. Based on these three qualities that were further explained in the manual, the team was able to efficiently made concept models that can realistically be produced in the time limit given for the class. The team was also able to get a better understanding of how we brainstorm. Most of the work done thus far on the AEV has been outlined by specific instructions in the manual, however, being able to practice creativity and innovation regarding the project was a new concept for lab progression. In terms of takeaways from code programming, the team was now able to troubleshoot the code based on track performance. While only test was able to be performed, exploring how the program physically translates on the track was important for understanding how to avoid wasting time with mistakes in the code script.

Lab 2 was broken up into two parts, the introduction of AEV track movement through programming, and the evaluation of AEV propulsion. During Lab 02a: External Sensors and System Analysis 1, Team F took on several tasks in order to become familiar with the external system hardware and their corresponding program calls. Before starting the lab, the team constructed a preliminary AEV in order to have a functional mechanism to test during the lab. External reflectance sensors and track wheels were introduced to the model AEV. The sensors were installed into the Arduino system through wires, and all further actions taken were performed through the programming system. The team used prearranged code in order to test the performance of the sensors, and explored how the orientation of the sensors affected the direction that the AEV traveled. The relationship between  “marks” and wheel revolution was also explored with the system function calls. Based on the Arduino code execution, the team used troubleshooting techniques acquired in the first lab to improve the functionality of the system through physical adjustments and changes in the original program. The team then used knowledge obtained about how the sensor code works, and created a program based on criterion given in the lab with the goal to formally test the sensors in front of an instructional team member. The testing portion of this lab was pushed to Lab 03 due to lack of time.

During Lab 02b: System Analysis 1: Propulsion Efficiency, Team F explored propulsion system efficiency through wind tunnel testing. In this case, efficiency is referencing the ability of the system to avoid wasting energy. The wind tunnel apparatus used was composed of a speed controller, power supply, thrust stand, and data acquisition system. The team measured the power output of the motor/propellor structure, and evaluated the efficiency based on the output and input values recorded during testing. After testing, the team worked on data analysis. Values such as thrust and the propellor advance ratio were calculated and interpreted based on the values that the team came up with. Based on the graph made through data collection, the 3030 pusher propeller had the highest propulsion efficiency, power output at the same power input as the other propellers, and advance ratio. This means that when the 3030 propeller-driven vehicle is moving at high speed relative to the fluid (in this case, air), the propulsion efficiency increases to a certain degree.

The errors throughout this lab provided a decent amount of insight to what needs modifying in order to complete the scenario stated in the Mission Concept Review. First off, the code needs to be modified in a way that the propellers rotate in order to propel the AEV forward. This could be done by reversing the propellers in the current code in order for them to rotate the correct way. It was also learned that the motorSpeed would have to be set to at least 60% in order for the AEV to be able to move. This is an easy fix, simply modifying the motorSpeed() command in the code.
The progression of this lab, like the one before, improved through team delegation. Since the team saw effective results in lab performance from the separation of tasks, it was decided to continue with this method in all further labs. Since most of this lab consisted of work with the Arduino program and experimental testing, each member was able to have a new role in testing. Through programming, the team is still developing familiarity with how the Arduino translates each command. Because a new component was added to the system (sensors), new calling functions were needed to improve functionality. Through this lab, the team is also learning how to work outside of class with the AEV due to shortages of time in the in-class lab sessions. Being able to construct parts of the AEV before coming into class, and looking at the code after class in order to continue troubleshooting, are just a few things that the team has done outside of lab time to avoid falling behind.

During Lab 01: Arduino Programming Basics, Team F took on several tasks in order to become familiar with the tools used to produce a functioning AEV.  This lab introduced the corresponding hardware and software for the AEV, allowing the team to explore all aspects of the project. In relation to the hardware, steps were given to set up an apparatus to test the propellor functions. The AEV controller, propellers, motors, and Li-Po battery were assembled in preparation of the function code. The aforementioned software was developed through analysis of code descriptions which outlined desired motor functions. Once the developed code was compiled and loaded into the AEV, the team observed its execution and began to  troubleshoot the program depending on undesirable actions.

The execution of this lab saw progression through team delegation. Team F divided itself into two parts, allowing two members to develop the code and two members to assemble the propellor apparatus. This system not only allowed all of the members to become familiar with their delegated tools first-hand, but allowed for a more efficient lab process. Once achieved, the combination of software and hardware gave Team F a stable foundation to begin preparing the programmed actions and physical framework for the final AEV system. This lab, essentially, gave the team an opportunity to learn not only what the dynamic of successful lab sessions looks like, but also discover what aspects of the AEV system they enjoy and/or what aspects they are having trouble comprehending for future reference.

Takeaways:

1. Identified how each digital command translated in the physical motors.
2. Learned how to fix any coding problems that arose in program execution.
3. Discovered that time can be saved and consensus achieved through delegation methods.
4. Became familiar with efficiently executing step by step processes.