This week, the team focused on energy optimization. In the past two performance tests, the group has come up with a design that consistently completes all of the requirements of the MCR. The team has also determined that writing a code based on time, instead of distance will work better for the designed AEV. This was mainly due to the complications the team faced when working with the reflectance sensors, which did not seem to be working and counting the number of marks, even when placed in the correct spot on the Arduino and much troubleshooting. Using what the team has concluded from previous performance tests, the team worked on testing variations of code on the Arduino program to ensure the most efficient run with the current design of our AEV. This will include decreasing the power as much as possible, finding when is the best time to cut power to the motors before it approaches the gate, and alter what type of commands are used in the code. The Data Analysis Tool and AEV Data Recorder was used throughout this week so that the group can compare individual runs and determine the most efficient code and use that in the final testing.
One of the conclusions that the team had decided was to discontinue with the idea of 3D printing an object that would provide increased balance and aesthetics to the AEV. Much of the reason for this was that our AEV is currently as lightweight as possible, and in order to attach another 3D printed object on top of our current design, the team would need to add an extra part to attach our 3D printed object, forcing the team to redesign the AEV and even modify the code with respect to time as it would increase the overall weight. This would make the team be constrained for time and make it even more difficult to get a complete and successful run of the AEV.
For the past week, the team had decided to test out using different motorSpeeds in order to conserve energy. Below are the two Power vs. Time figures which show the performance tests for the first quarter runs when using a motorSpeed of 25% and a motorSpeed of 30%. Since the team is using time, the team had to alter the goFor (time function) in order to make the AEV get to the first part of the gate. Below the figures are the tables which list the breakdown of the two phases for the first quarter run of each AEV run, with the total (approximate) energy expended for each quarter run given below the graphs.
Table 2: Phase breakdown of incremental energies for first quarter run using a motor speed of 25%
| Phase | Arduino Code | Time (seconds) | Total Energy (Joules) |
| 1 | reverse(2);
motorSpeed(4,25); goFor(9); |
9 | 5.8 * 9 = 52.2 J |
| 2 | celerate(4,25,0,2);
(goFor(8); – for stopping at gate) |
2 | ½ * 5.8 * 2 = 5.8 J |
Total Energy: 58 Joules
Table 2: Phase breakdown of incremental energies for first quarter run using a motor speed of 30%
| Phase | Arduino Code | Time (seconds) | Total Energy (Joules) |
| 1 | reverse(2);
motorSpeed(4,30); goFor(6.1); |
6.1 | 7.5 * 6.1 = 45.75J |
| 2 | celerate(4,30,0,2);
(goFor(8); – for stopping at gate) |
2 | ½ * 7.5 * 2 = 7.5 J |
Total Energy: 53.75 Joules
As can be seen from both the figures and the tables, surprisingly enough using a higher motorSpeed will result in a more efficient design. This is mainly due to the fact that the motors that run the propellers are on for a smaller amount of time to get the AEV to the same location. Therefore, the team has decided to use a high enough motorSpeed that will save the most energy (in other words, be the most energy efficient) and finish the mission to save the R2D2 in under two minutes and 30 seconds.
For the past week, the team had decided to experiment using the ServoMotor, which essentially is an optional part for everyone’s AEV that will stop the wheels from turning when the code for rotating the servoMotor is established in the Arduino code and uploaded into the Arduino program. The team expected to get better results in stopping the AEV in a crisper, cleaner and more reliable way. However, what the team found was more complications with stopping the AEV at the gate. In fact, the team had tried numerous types of code, including reversing the motors and trying to decelerate backwards (using the reverse() and celerate() functions) to have a crisper stop along with turning the servoMotor to stop the wheels from turning. The team found itself changing the goFor time back and forth to similar amounts of time, and each run would be different from the next. This led the team to conclude that going back to Lab 08’s code, where the team was able to get a successful run using time. The only disadvantage with this is that the AEV will be coasting along the track, but at the same time will use much less energy as no energy is expended in trying to stop the AEV. However, the team will still work on code to make the AEV have a smooth stop before the gates once it is able to successfully complete the mission using the code developed in Lab 08A, 08B and 08C.
Code
reverse(4); //Reverse all motors.
motorSpeed(4,45); //Power all motors to 45% speed.
goFor(8); //Maintain 45% speed for 8 seconds.
celerate(4,45,0,1); //Decelerate all motors from 45% power to 0% power in 1 second.
rotateServo(180); /Arduino Code
Quarter Run at 30% motor speed
reverse(2); //Reverse motor number 1.
motorSpeed(4,30); //Power all motors to 30% speed.
goFor(6.1); //Maintain 30% speed for 6.1 seconds.
celerate(4,30,0,2); //Decelerate all motors from 30% speed to 0% speed in 2 seconds.
goFor(8); //Continue to brake for 8 seconds.
Quarter Run at 25% motor speed
reverse(2); //Reverse motor number 1.
motorSpeed(4,25); //Power all motors to 30% speed.
goFor(9); //Maintain 30% speed for 6.1 seconds.
celerate(4,25,0,2); //Decelerate all motors from 30% speed to 0% speed in 2 seconds.
goFor(8); //Continue to brake for 8 seconds.
Full Run
reverse(2); //Reverse motor number 1.
motorSpeed(4,30); //Power all motors to 30% speed.
goFor(8.25); //Maintain 30% speed for 8.25 seconds.
celerate(4,30,10,1); //Decelerate all motors from 30% power to 10% power in 1 second.
reverse(4); //Reverse all motors.
celerate(4,10,0,1); //Decelerate all motors from 10% power to 0% power in 1 second.
rotateServo(180); //Rotate the servo arm 180 degrees.
goFor(8); //Wait for 8 seconds.
rotateServo(0); //Rotate the servo arm back to its original position.
reverse(4); //Reverse all motors.
motorSpeed(4,30); //Power all motors at 30% speed.
goFor(7.5); //Maintain 30% speed for 7.5 seconds.
celerate(4,30,10,1); //Decelerate all motors from 30% power to 10% power in 1 second.
reverse(4); //Reverse all motors.
celerate(4,10,0,1); //Rotate the servo arm 180 degrees.
goFor(0.5); //Wait for 0.5 seconds.
rotateServo(0); //Rotate the servo arm back to its original position
goFor(6); //Continue to brake for 6 seconds.
/Rotate the servo arm 180 degrees.
goFor(8); //Wait for 8 seconds
motorSpeed(4,45); //Power all motors to 45% speed.
goFor(8); //Maintain 45% speed for 8 seconds.
celerate(4,45,0,1); //Decelerate all motors from 45% power to 0% power in 1 second.
rotateServo(180); //Rotate the servo arm 180 degrees.
Team Meeting Notes
Meeting 15
Date: 09-Apr-2017
Time: 2:00-3:30 PM
Location: Hitchcock Hall, Room 324
Members Present: Omar Mahboob, Xander Riggio, Matthew Spishakoff, Eric Fogle
Method: Face to Face
Meeting Objectives: Work on Week 10 Progress Report, update Project Portfolio, Discuss future plans for the code.
Roles for Meeting 15:
O Eric: Forward Looking Plan, Updating Project Portfolio
o Omar: Results and Analysis, Tables and Figures
o Xander: Takeaways, Arduino Code, Proofreading and Final Submission
o Matthew: Week 10 Situation, Team meeting notes, Reflections
Tasks Completed in Previous Meeting:
o Eric: Forward Looking Plan
o Omar: Results and Analysis, Tables and Figures
o Xander: Appendices, Proofreading and Final Submission
o Matthew: Week 9 Situation, Takeaways
Status– All assigned tasks have been completed. Project Portfolio has been updated. The future of the code has been discussed.
Decisions made by the group:
o Roles and responsibilities for Meeting 15
o Use of the servo motor will be scrapped
o No 3D part will be made for the AEV
o Team will go back to most successful code for future runs
Reflections:
Within the labs of week 10, the team not only learned about which bits of code are the most energy efficient to use, but whether or not the servo motor was the right thing to use for the AEV runs. Through this experimentation and analyzing the data retrieved from the runs, the team was able to come to two major conclusions. The first being that for the AEV design being used as well as the code, the most energy efficient option will be to have the AEV and arduino operate on a higher speed. As for the servo motor, it was decided that the use of the servo motor was not the best route for the team to take. This was due to the fact that the servo motor was simply not functioning properly. While running on the track, it would not deploy soon enough and the AEV would not stop, subsequently making it run into the gate. This was a consistent problem and one that seemed to have no solution. Since the team was using a higher speed, due to the efficiency, there was an attempt to stop the AEV using reverse and deccelerate functions. This combined with the servo being employed at the same time caused a delay in the servo’s deployment. Due to their being no practical solution for this issue, the team has decided to do away with the servo entirely. The team will continue to further optimize the past code used perform runs with that.