This week, the team worked to increase the AEV’s energy efficiency. The team’s main idea for increasing energy efficiency was to adjust the amount of power the AEV motors received. In total, the team tested 25%, 28%, 30%, and 32% power. In order to determine how energy efficient each power percentage was, the team adjusted the variables in the code (Appendix B) to ensure the AEV completed the run. The team then ran the vehicle on the track, observed the run, and then examined EEPROM data.
Additionally, the team cut off additional parts of the AEV and removed some of the metal chain used to connect to the R2 cargo. Based on the results of previous labs, the team theorized a lighter AEV would require less power to start moving. Overall, all of these procedures were done to ensure the AEV would be energy efficient for the Rebel Alliance.

Last week, the team wrote two scenario codes. Both codes had the AEV pickup the R2 unit and return to the start. Additionally, both codes had delays to have the AEV wait before the intermediary gate. The team’s first code relied on the distance the AEV traveled (Appendix B), while the second code was based on how much time the AEV traveled (Appendix C). Team member Travis wrote the distance-based code, while team member Joseph wrote the time-based code. Both codes were written in Arduino IDE. The team then repeatedly ran the AEV with each code on the track and adjusted variable values until the AEV traveled the correct distances for each segment of the scenario. A code was considered finished when the AEV ran it and successfully completed the entire scenario.
The team wrote the two codes for two primary reasons. First, a user-defined set of instructions is needed to complete the final scenario. It doesn’t matter how efficient the AEV is. If the AEV’s coded instructions are incorrect, the AEV will not be able to complete its mission. Second, the team wanted to determine if the final instructions should be based on how far the AEV traveled or on how much time it traveled. Writing the entire scenario for both techniques allowed the team to analyze and choose which was better.

The last lab was a catch-up week. It ensured segments of previous labs not completed due to time constraints could now get finished. Since the team had the most problems with the topics of the fifth lab, design screening and scoring, the group decided to redo its design matrices and make sure the AEV examination was correct. The team believed this testing would reveal the strengths and weaknesses of the current bottle-AEV design. Thus this information allowed the team to determine what parts of the design could be relied on and what parts would need improvement before the final testing.
The team started the design screening and scoring process by breaking into two two-person groups. One group looked over the previous screening and scoring rubric from last week to ensure it emphasized what the team cared the most about, which it did. The second group worked on writing code for testing (Appendix B). After this, the team ran the AEV on the table rail and compared it to the reference AEV for design screening. Finally, after the team reassured itself that the bottle-AEV was better than the reference, the bottle-AEV was run on the track and observed. The team then filled out the design scoring together and examined the bottle design for the last few minutes of lab.

This lab, the team worked on collecting data for how the AEV ran on the track through quantitative analysis. The quantitative analysis was very important to this project because it would later allow the team to objectively determine which AEV designs are better than the reference unit. The data would also give analysis on the AEV’s stability, which would allow the team to determine how much energy the motors could take before the AEV broke from the track and became a hazard.
In order to do quantitative analysis, the team first programmed a small script for the AEV to run (Appendix B). The team then ran the AEV on the track and recorded the run’s data using Electrically Erasable Programmable Read-Only Memory (EEPROM). The data was then transfer to an excel document, where team member Davin created graphs based on it and team member Max examined it with equations shown in Appendix C.

The team started developing a program to take the AEV from the track’s beginning to its end, just before the gate. Through this procedure, the team determined the required travel distance using the provided monorail schematic, ensured the AEV is balanced with the battery in its holder, and figured out what speeds the AEV can handle without falling off the track. When this program was first developed, it was tested locally on the desktop stand, and once it was shown to work, the team tested on the monorail. Assuring the AEV was balanced with the battery in its holder was critical to assuring the AEV traveled without issues. If the AEV fell off the track, it could be damaged.
In addition, the team began performance analysis of the AEV using Electrically Erasable Programmable Read-Only Memory (EEPROM). This data proved useful when trying to improve the AEV’s energy efficiency. To start, the team used an aevDataRecorder to save the AEV’s performance to a file. Next, the team examined this data using a custom MATLAB script that converted the data to physical values. The team then used midpoint Riemann sums to estimate the total energy used.

The following lab, team member Max worked alone to collect wind tunnel data. The point of this data was to determine what amount of thrust would allow the propellers to be as energy efficient as possible. Max did not personally collect the data. Instead, it was provided to him and members from other groups by a UTA who had control of the propeller and wind tunnel. After returning to the team table with the data, Max employed Davin to perform calculations. The original data and Davin’s analysis can be seen below.

Wind Tunnel Data

Davin’s Wind Tunnel Data Analysis

In the this lab, the team experimented with the AEV’s reflectance sensors. Two new functions, goToAbsolutePosition(x) and goToRelativePosition(x), were made available to the group. In addition, the team performed wind tunnel testing on different propeller designs. The two new functions were important because they allowed the AEV to travel precise distances. Meanwhile, the wind tunnel testing was important because it helped the team determine whether a pusher or puller propeller design was more efficient for the AEV. Using the best design will make the AEV more energy efficient.
In terms of procedure, the team started by assembling the AEV. While three members ensured the vehicle was properly built, the last member performed wind tunnel testing with the pusher and puller propeller designs. Next, the team wrote a short segment of code in Arduino IDE to ensure the reflectance sensors were working and position function calls were returning values (Appendix B). The AEV went through this code on a small railing at the team’s work center. Finally, the team quickly wrote code and ran the AEV on the track (Appendix B).

During this lab, the team created an AEV design that used a bottle as a base. The design was then compared to the reference unit to see if it was more energy, time, or cost efficient. The team had hope that the low cost, lightweight, and readily-available design would prove to be a possible candidate for the final problem. The screening and scoring helped the team decide if it was.
The team started by creating an excel sheet for examining designs. Originally, the team had planned to create and test multiple AEV designs, but the bottle design took a while due to a dearth of tools that could pierce plastic. The team eventually cut out the bottom of the bottle and attached all the AEV components to the inside. Finally, the design was run on the test track and then compared to the reference.

Design screening

Design scoring

In Lab 1, the team created and ran its first pieces of arduino code. The sections of software were run on a two-propellered machine that had a separate motor for each propellor. Using this device, the team was able to test powering different motors for different amounts of time. From this, the team discovered how to setup the AEV software, learned how to find coding errors, and became familiar with some of the methods available on the arduino. Understanding these basics gave the team a strong foundation that will be built upon as more arduino methods become available for the project.

In terms of procedure, the team first mounted propellers and then ensured the arduino was connected to a battery. Next, the team opened the AEV Sketchbook files in Arduino Integrated Development Environment, abbreviated Arduino IDE. From there, the team was able to type out code in a syntax similar to C++. The arduino was then connected by an arduino-to-USB cord to the computer running the Arduino IDE. At last code was sent and run on the arduino.

In the third lab, the team individually then collectively brainstormed different AEV designs. The team did this to improve its communication skills and to create a unique plan that would make the AEV both energy and cost efficient. At the start of the lab, one team member setup and started a fifteen minute timer. During this time, team members individually thought about different ideas and designs. After the timer went off, the team collectively discussed the AEV’s design for another twenty minutes. A whiteboard was used for visualization. In the end, the team built upon a design brought to them by a teaching assistant. The expanded design can be seen below.

The team’s collaborative design.