Final Code

reverse(2);                    //Reverse one motor so they both blow the same direction

celerate(4,0,45,3);      //Accelerate both motors from 0 to 45% over 3 sec

motorSpeed(4,25);     //Both motors at 25% until ~13 ft. away from start



motorSpeed(4,25);     //cut and reverse over 3 feet



brake(4);                       //No motor activity for 7 sec


celerate(4,0,45,3);     //Accelerate both motors from 0 to 45% over 3 sec

motorSpeed(4,30);    //both motors at 30%

goToAbsolutePosition(625);    //~25ft away from start

brake(4);                     //No motor activity


brake(4);                    //Stop to secure R2


reverse(4);                  //Return position

celerate(4,0,70,5);      //Accelerate both motors from 0 to 70% over 5 sec

motorSpeed(4,45);      //both motors at 45% part of the way back


motorSpeed(4,25);     //both motors at 25% until ~21 ft. from track start



motorSpeed(4,25);     //cut and reverse over ~2 feet



brake(4);                      //stop at gate on way back


celerate(4,0,70,5);     //Accelerate both motors from 0 to 70% over 5 sec

motorSpeed(4,45);      //both motors at 45% until 7 feet away from start


Lab 10

Date: 31 – Mar – 2017 to 6 – Apr – 2017

Time: 11:10 AM (Face-to-face)

Members Present: Olivia McNeil, Derek Gupta, Lauren Hole, Samantha Flora

Topics Discussed: Lab 10

Objective: Lab 10 was focused on getting the AEV to run consistently on the upstairs track in order to finalize the code. The team brainstormed about how to combat the problem of the downstairs and upstairs tracks being different. The team also had the task of modifying the code in order to counteract the inconsistencies due to the change in the AEV’s weight.

Tasks Completed:

  • Modifying code (All Members)
    • AEV could run most of the MCR successfully but it needed help stopping at gates
    • Majority of time spent adjusting the code for gate stops
    • Adjusted code on a Trial-and-error/as-needed basis
    • Inconsistencies from battery life, sensor reception, bumps in the track
    • current code worked best when it was the 2nd trial in the battery’s life
    • Able to complete all aspects of the MCR during that run
  • Energy Optimization
    • Not much time was spent in this area since getting the code to actually work took a higher precedence
    • When code was adjusted for gates, energy usage was considered
  • Downstairs Track (All Members) **This happen during Lab 11A, but is still important to report**
    • The same code used on the upstairs track worked surprising well, if not better on the downstairs track
    • less energy used on downstairs, Final testing should have been done there!!!
    • The team tried to account for the loss in battery life when testing, however changing the battery only made testing worse

Upcoming Tasks:

  • Fix all hiccups in run and finalize code for performance test on upstairs track
  • Decide the logistics of testing (which day? which trial will be testing trial? etc.)
  • Practice giving CDR Oral Presentation
  • Work on CDR Report


Many experimental limitations came to the team’s attention this week. Trying to perfect the code has become extremely difficult due to these limitations. During the shorter lab classes (Tuesday and Thursday) it is hard to test more than four times due to time limitations, which doesn’t give enough data for how many corrections the team needs to make. The batteries die quickly, which can completely change how the AEV performs. The team needs to check the voltage of the battery before and after runs to monitor when the battery needs switched and to tell which voltage produces the best performance. In hindsight, the team should have done the graded runs on Friday Lab 11 A.

Lab 9

Date: 24 – Mar – 2017 to 30 – Mar – 2017

Time: 11:10 AM (Face-to-face)

Members Present: Olivia McNeil, Derek Gupta, Lauren Hole, Samantha Flora

Topics Discussed: Code


The focus of Lab 9 was on the AEV code and specifically its efficiency, consistency, flexibility to changes in the track. The Team needed to modify the chosen code from PDR to fill out more of these qualities. By the end of this lab, the code should be nearly completed and be able to accomplish the MCR without any major obstacles

Tasks Completed:

  • Modifying the Code (Derek)
    • Reverse functions (seen in Code 1) were incorporated into Code 2 since this function gave Code 1 more performance consistency
    • AEV runs its motors in reverse during a certain position on the track rather than by a selected amount of time
  • Performance Analysis (All Members)
    • The team modified the code in lab on an as-needed basis, using hiccups in the trials to program the next step
    • The most time was spent adjusting the portion that the AEV reverses on
  • Test With Gates On
    • The AEV ran the track with the gates on for the first time, the team did not mean to have gates on, but the AEV accomplished the MCR

Notes on AEV Performance:

  • AEV runs slow on track, making the best of efficiency
  • AEV is stable and does not wobble
  • When the AEV hit zero velocity while still in its reversing portion of the track, it began to move backwards, which failed the rest of the code
  • Better overall consistency  than Code 2 and Code 1

Upcoming Tasks:

  • Final look at energy analysis
  • Testing energy efficiency between most recent code and Code 1 and Code 2
  • Test with the gates turned on
  • Taking inconsistent environmental factors into consideration


It isn’t easy to tell the difference between the upstairs and downstairs tracks. A TA informed the team that the lighting in one of the rooms affected the reflectance sensor. If that is the case, then the team does not see an ideal way of correcting that environmental change. At this point in the project it may not be worth writing a full new code, hopefully the track we test on will run similar to the track used in the upstairs, since most of our testing is done there. The team will also brainstorm on how to fix this obstacle.

Week 10

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.

Week 9

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.

Lab 7

Date: 3 – Mar – 2017

Time: 11:10 AM (Face-to-face)

Members Present: Olivia McNeil, Derek Gupta, Lauren Hole, Samantha Flora

Topics Discussed: Oral Presentation

Objective: The focus of the PDR Oral Presentation was to convey the progress made on the AEV to the TAs and other groups in a formal manner. The team should pay attention to other groups’ presentations in order to compare ideas and learn from other groups’ mistakes.

Tasks Completed:

  • Background and Coding Progress (Derek)
    • Presented MCR and elaborated on current ability of the code
  • Concept Design and Performance Goals (Lauren)
    • Presented current design
    • Mentioned weight distribution issue and introduced implementation of new blades
  • Future Plans & Website Progress (Olivia)
    • Mentioned future tests with R2 unit and personal touches to website
  • Teamwork & Development History (Samantha)
    • Presented setbacks within lab-work and major decisions made throughout progress

Upcoming Tasks:

  • Rebuild the AEV to test the two different best designs
  • Test each design for energy efficiency and performance quality
  • Learn how the addition of the R2D2 unit affects the energy efficiency and performance
  • Learn how the new propellers will affect the energy efficiency and performance
  • Collect the data needed for the Results section of the PDR Report
  • Split up assigned work for the PDR Report


The team did not receive as high of a score as anticipated. This was probably due to the lack of raw data presented in the presentation. Also, team members did their best job to elaborate when asked questions by the GTA, however the group could have been more prepared. The team should spend more time prepping the presentation next time.