Situation
For the labs of week 9, the group focused on establishing a specific type of code with which they will continue to use for the final testing and showcasing of the AEV. The team was deciding on either of two types of code to use: the first was based on time (mainly using the function goFor() in the Arduino software) and the second code was based on distance and marks based off of the readings from the Arduino nano microprocessor to the reflective sensors. To decide which type of code to use, the team attempted to create two working codes that utilized each. Doing this was a critical step for the group as the date of the final test is approaching. The importance lies in how crucial the code of the AEV is, as using the proper code for the situation can minimize the amount of energy used and provide reliable runs.
Results and Analysis
The first code the team decided to use was based off of time. This was done as the team had initially had problems with the reflective sensors in the past and wanted to get a successful run so as to download the data from the Arduino processor onto MATLAB and record a performance analysis which compared the power used with respect to time. The team had included all the results and analysis of the data in the Preliminary Design Report the team had just written in the past week. The team was able to get the first part of the code in, which was to move the AEV to the first part of the track, to the gate and stop for a total of 7 seconds. The team found that it was able to achieve this relatively quickly through discussion and trial and error, and the team was able to progress relatively quickly through that. In fact, during labs 08B and 08C, the tam found that it made significant progress with developing the code with respect to time.
This testing with respect to time came after the team had decided to redesign the AEV to what the team had found to be the most efficient, cost-effective, aerodynamic and balanced AEV, which was our vertical design. An image of this vertical design is posted below for reference. This design, as explained previously in the PDR, had replaced our initial ideas of having an A-wing and Alpine Swift combination in exchange for a simpler vertical design that proved to run on the track. This success is mainly attributed to the fact that our design was able to have a lower center of mass, and so pull the wheels on the AEV down on the track to make sure both make contact with the track and so can spin effectively and not come off the track. As this design had proven to be our most effective design, the team has decided to base our last final runs on this one and if needed 3D print our designs to fit into this current one. One of the objectives still maintained by the team is to 3D print a design that will provide increased stability by lowering the center of mass, which may increase the overall weight but in essence cause the AEV to decelerate faster when the motors are slowed down and stopped using celerate() and brake(). The pre-Alpha stage of this design, with its dimensions based off of a SolidWorks drawing are shown below in the Appendix. This is the only redesign considered for our AEV at the moment, as our design seems to have no place for any additional material (both physically and for the reason that the team wants the AEV to be as light as possible to optimize energy efficiency).
Figure 1: Vertical AEV Design
During this past week, the team decided to test the AEV using code based off of absolute position (using the function goToAbsolutePosition()). The team had to slightly redesign the AEV to attach the Arduino nano microcontroller the other way around as the reflective sensors were not able to attach into the correct place. One of the problems that had arisen from this redesign, as because there was not enough space on much of our AEV, the arduino processor had to be attached very loosely with only two screws to hold it in. Even though the Arduino held in place, it seemed as though this design was not aesthetically pleasing to look at, let alone keep as our final design. The team was going to be unable to explain this design and so the team was most probably going to have to completely redesign the AEV, which would have taken a while as the team would have to figure out how each part of the AEV was going to have to be positioned so that the AEV could have a successful run.
One of the biggest issues faced by the team in using position in our Arduino code was that the team was unable to get the AEV to stop. After performing a reflectiveSensorTest() with our AEV, the team had found that there were multiple issues making the Arduino process this one line of code and for the test to start on the Serial Monitor. The team had found later that the issue was that the reflective sensors were not connected in the correct orientation and in the current part of the Arduino, and not just have the white lines face the USB port (as that what seemed to be implied in the lab manual). This proved to be a big obstacle as the construct of our AEV did not make it easy to connect the reflective sensors, but with effort the team was eventually able to connect the reflective sensors. Even when the reflective sensors were attached in the correct orientation and the reflectiveSensorTest() was successful and working, the team found that the wheels had to be turned profusely until it would reach the required number of marks for the first half of the outer part of the track.
This proved to be a problem as the team could not do simple arithmetic and go with the convention that one mark was equivalent to 0.4875 inches, as implied in the lab manual. In fact, when the team would test using a position of 400 marks (equivalent to 16.25 ft), which was shorter than the first part half of the track (which measured a distance of ~18.5 feet) , the AEV would not stop. The team even tested the code with an absolute position of 10 marks (equivalent to 0.406 feet) and the team had to spin the wheel for a long time before the motors turned off. The team has therefore concluded that it will use time to complete the run as a result of these issues. Even though time may be hard to perfect, it is currently the only option the team has due to its current circumstances.
Below is a table based off of the Mission Concept Review on the breakdown of the run required of every team to complete the AEV mission to save the R2D2, and some analysis of the way Team C will tackle the different sections of the run. The track is conveniently divided into 4 equal sections and so the time code may be run the same for the first two parts of the track but will have to be adjusted due to the increased weight when the AEV is bringing the R2D2 back to base.
Table 1: Breakdown of objective as outlined in the Mission Concept Review and
Team C’s prospective Arduino Code
| Section | Distance Covered/Time taken | Prospective Arduino Code |
| Mark 1 → 1st sensor before gate | ~ 18.5 feet | Refer to PART 1 below |
| Stop at the gate | 7.0 seconds | Refer to PART 1 below |
| 1st sensor before gate → R2D2 | ~ 18.5 feet | Refer to PART 2 below |
| Stop for 5 seconds to ensure cargo is attached | 5.0 seconds | Refer to PART 2 below |
| R2D2 → 2nd sensor before gate | ~ 18.5 feet | Refer to PART 3 below |
| Stop at the gate | 7.0 seconds | Refer to PART 3 |
| 2nd sensor before gate → drop-off area | ~18.5 feet | Refer to PART 4 below |
PART 1
reverse(1); //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.
brake(4); //Brake all motors
goFor(8); //Continue to brake for 8 seconds.
PART 2
motorSpeed(4,30); //Power all motors at 30% speed.
goFor(6.5); //Maintain 30% speed for 6.5 seconds.
brake(4); //Brake all motors.
goFor(9); //Continue to brake for 9 seconds.
reverse(4); //Reverse all motors.
PART 3
motorSpeed(4,45); //Power all motors to 45% speed.
goFor(7.25); //Maintain 45% speed for 7.25 seconds.
celerate(4,45,0,2); //Decelerate all motors from 45% speed to 0% speed in 2 seconds.
brake(4); //Brake all motors.
goFor(8); //Continue to brake for 8 seconds.
PART 4
motorSpeed(4,45); //Power all motors to 45% speed.
goFor(8); //Maintain 45% speed for 8 seconds.
brake(4); //Brake all motors.
Team Meeting Notes
Meeting 14
Date: 02-Apr-2017
Time: 2:00-3:30 PM
Location: Hitchcock Hall, Room 324
Members Present: Omar Mahboob, Xander Riggio, Matthew Spishakoff (Eric Fogle online)
Method: Face to Face
Meeting Objectives: Work on Week 9 Progress Report, update Project Portfolio.
Roles for Meeting 14:
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
Tasks Completed in Previous Meeting:
o Eric: Executive Summary, Introduction, Appendix B, Design #2
o Omar: Data Graphing, Results and Analysis
o Xander: Appendix A, Appendix C, Proofreading and Final Submission
o Matthew: Experimental Methodology, Appendix B, Design #1
oTeam- Conclusions and Recommendations
Status– All assigned tasks from the previous week have been completed. This week’s progress report has also been completed. The team has made two successful test runs using the time-based code. The team will meet this Tuesday in order to complete the Oral Presentation Draft. A 3D-printed part for the AEV is currently being worked on.
Decisions made by the group:
o Roles and responsibilities for Meeting 14
o The team will complete the Oral Presentation Draft in the next meeting.
o The 3D printed part will be worked on individually after the meeting.
o The team will then meet next weekend for next week’s progress report.
o Team will use its time-based code for most, if not all future test runs.
Reflections: In week 9, the group attempted to revisit the reflectance sensors, and use them to conduct a successful test run with a position-based code. The outcome was less than spectacular. The AEv was redesigned in order to incorporate the reflectance sensors, with limited success. The main two issues this new design presented came from the position of the wires, and the reflectance sensors themselves. Being a vertical design, the team’s AEV was limited in where the Arduino could be placed on the AEV where the reflectance sensors could be physically plugged into the Arduino in the correct manner. The placement of the battery holder, propeller, and top hangers added even more constraints to a design that did not have a lot of space to offer in the first place. While this limited space helped cut down on the designs mass, making it more efficient, it did not provide much room to contain all of the components that are necessary for the AEV to run. Nonetheless, the team made a design that accommodated all of these parts. However, after attempting to test this design, one of the motors blew out after it malfunctioned, span very rapidly for several seconds, damaged the propeller, and then was shut off by the team. The motor and propeller were replaced and the error cost the team 10 minutes of a 55 minute session. Then, the wires of the battery and propellers became a problem, as they started falling out of their set positions, getting in the way of the propellers, and costing the team even more time. This was fixed, and the team finally attempted to complete a test run using its position-based code. The AEV did not stop moving in the test run, and it had to be stopped manually by a team member. The team then attempted to use the test track with measurements underneath to test its position based code for accuracy. However there was not enough time left in lab at this point to successfully run these test, let alone complete another actual test run.
Overall, the team realized from this lab that it is likely more optimal to invest future lab time into perfecting the time-based code, rather than continuing to deal with the position-based code and reflectance sensors. The team had great success in week 8 working with the time-based code, completing two successful runs and many successful partial runs in the process. That being said, the team may spend one lab in the future attempting a position-based rune one last time, as the team feels the position-based code would be better than the time based code if optimized. An optimized position-based code would allow for the AEV to stop and start in a more precise manner than an optimized time-based code, which would be valuable considering that the AEV needs to stop in a precise manner three time during the actual mission. However, the difficulties the team has had in attempting just one run with position based code outweigh the potential benefit an optimized position-based code could offer, and an optimized time based code would not be too much worse than an optimized position-based code anyway. With all of this in mind, the group is heading into week 10 ready to build off its success from week 8, continuing to test and modify the time-based code, so that it will be fully optimized in time for the AEV’s final test run.