Lab 09 Progress Report (04/03/17)

Situation

The second performance test focused on evaluating the coding for the AEV by comparing two different codes from the team and determine which code accomplishes the objective while fulfilling the constraints of high energy efficiency. The importance of this test is to evaluate how consistent the performance of the AEV would be for the final test. For the first code, the AEV would try to complete the objective purely by accelerating and coasting. The second code would try to brake the AEV with a servo motor. By running several runs for each code, the team observed the run and evaluated the data collected. This testing is necessary to compare which code has a more consistent performance while fulfilling the constraints.

 

Results & Analysis

In the beginning of the second performance test, the AEV performed nicely when it pass through the gate, but was unable to drag the payload pass through the return track. However, after a few runs, the team discovered that the AEV perform quite differently with each run, and has to made modifications to the code to continue the testing. Due to errors from MATLAB, the group can not get any results, so their results are based on observation.

The distinguishable differences in the codes was that the group took more consideration in the coasting abilities of the AEV. The AEV was also slowed down way way sooner than it was able to make it to the gate. The issue will this is take the AEV is stopped before the gate, then slowly proceeds to it afterwards, but this adds additional time to the runs and additional things to consider in the code. The energy efficiency has improved because there is less power needed to run the AEV.

 

Table 01: Breakdown Distances

No.

Track description

Distance Wait time
1. From the start point to the gate. 190 inches 7 seconds
2. From the gate to the payload. 207 inches 5 seconds
3. From payload retrieval to the gate. 190 inches 7 seconds
4. From the gate back to the start point. 207 inches None

Takeaways

  1. General – Take into consideration of external factors might affect the AEVs performance.
  2. Specific – Take into consideration that different batteries hold different charge and the coding should be adjusted slightly to accommodate that.
  3. Specific – Each run depletes the battery power by a certain amount, so batteries should be swapped out after a few runs otherwise the AEV’s performance would vary even though the coding remains the same.

 

Weekly Goals

  1. Adjust the coding to accommodate the new design that is laser cutted.
  2. Able to lower the power consumption to below 180 J.
  3. Add the acrylic base to the AEV
  4. Modify the code to consider the new weight of the AEV, which includes changing the speed, braking, and coasting distance

 

Weekly Schedule

Table 02: Week 11 Schedule

Task Teammate(s) Start Date Due Date Time Needed
Replace the AEV with the new part Ameeya 03/31/17 04/03/17 1-2 hours
Modify the final code for the new AEV design All 04/03/17 04/07/17 TBD
Extra credit video Teck Yang 3/28/17 04/24/17 TBD

 

Appendix A

Performance Test Utilized Code 1

celerate(4,0,30,0.5); //Accelerate all motors from 0% to 30% in 0.5 seconds.

goToRelativePosition(100);

brake(4); //Brake all motors for 10 seconds when it read 110 marks.

goFor(10);

int absolutePosition = getVehiclePostion(); //stores AEV’s absolute position into an integer.

 

//if AEV overshoots the second sensor

if (absolutePosition > 409) {

reverse(4); //reverse all motors

celerate(4,0,13,0.1); //accelerate all motors from 0% to 13% power in 0.1 seconds.

goToAbsolutePosition(400);

brake(4); //brakes all motors for 7 seconds when AEV reaches the middle of two sensors.

goFor(7);

}

//if AEV didn’t reach the first sensor

else if (absolutePosition < 392) {

celerate(4,0,13,0.1); //accelerate all motors from 0% to13% power in 0.1 seconds.

goToAbsolutePosition(400);

brake(4); //brakes all motors for 7 seconds when AEV reaches the middle of two sensors.

goFor(7);

}

//if AEV is in between the two sensors

else{

brake(4);// brakes all motors for 7 seocnds

goFor(7);

}

 

celerate (4,0,30,0.5); //accelerate all motors from 0% to 30% power in 0.5 seconds.

goToRelativePosition(125);

brake(4); //brake all motors for 15 seconds when it read 125 marks.

goFor(15);

 

reverse(4); //reverse all motors

celerate (4,0,30,0.5);//accelerate all motors from 0% to 30% power in 0.5 seconds.

goToRelativePosition(-125);

brake(4); //brake all motos for 10 seconds when it move 125 marks backwards

goFor(10);

 

//if AEV overshoots the second sensor

if (absolutePosition < 432) {

reverse(4); // reverse all motors

celerate(4,0,10,0.5); //accelerate all motors from 0% to 10% power in 0.5 seconds.

goToAbsolutePosition(440);

brake(4); //brake all motors for 7 seconds when it is between two sensors

goFor(7);

}

//if AEV didn’t reach the first sensor

else if (absolutePosition > 440){

celerate (4,0,10,0.5); //accelerate all motors from 0% to 10% power in 0.5 seconds

goToAbsolutePosition(440);

brake(4); //brake all motors for 7 seconds when it is between two sensors.

goFor(7);

//if AEV is between two sensors

else {

brake(4);

goFor(7);

}

 

celerate (4,0,30,0.5); //accelerate all motors from 0% to 30% power.

goToRelativePosition(-125);

brake(4); //brake all motors for 15 seconds when it move 125 marks backwards.

goFor(15);

 

Performance Test Utilized Code 2

celerate(4,0,30,0.5);//accelerate all motors from 0% to 30% power in 0.5 seconds

goToRelativePosition(140);

brake(4);//brake all motors when AEV reads 140 marks

goToAbsolutePosition(390);

rotateServo(90.00); //rotate servo 90 degrees clockwise when AEV reads 390 marks

goFor(1);

rotateServo(-90.00);//after 1 second, rotate servo 90 degrees anticlockwise

goFor(7);

 

celerate (4,0,30,0.5);//accelerate all motors from 0% to 30% power in 0.5 seconds

goToRelativePosition(135);

brake(4);//brake all motors when AEV reads 135 marks

goFor(13);

 

reverse(4);//after 13 seconds, reverse all motors

celerate (4,0,50,0.5);//accelerate all motors from 0% to 50% power.

goToRelativePosition(-140);

brake(4);//brake all motors when AEV reads 140 marks backwards

goToAbsolutePosition(440);

rotateServo(90.00); //rotate servo 90 degrees clockwise when AEV reads 440 marks

goFor(1);

rotateServo(-90.00);//after 1 second, rotate servo 90 degrees anticlockwise

goFor(7);

 

celerate (4,0,50,0.5);//after 7seconds,accelerate all motors from 0% to 50% power in 0.5 seconds.

goToRelativePosition(-125);

brake(4);//brake all motors when AEV reads 125 marks backwards

 

Appendix B

Team Meeting Notes

Date: April 2, 2017

Time: 9am-12pm

Members Present: Teck Yang Koh, Ameeya Watkins, Brisa Reyes, Justin Western

Topics Discussed: Progress Report, code modifications  

Objective:

Discuss the AEV’s progress and determine how the AEV will likely perform in the final run.

 

To Do/ Action Items:

  • Evaluate code to accommodate the slight design changes.
  • Finish the Week 11 Progress Report
  • Construct the AEV using the new part

 

Decisions:

The has changed changed the AEV by adding their new acrylic part that was made. The group determined the the overall AEV code is working well, but will need to be tested and updated with the new addition to the AEV.

 

Reflections:

The group need to focus on progress their code more, so they can come near to completely the length of the full track. It will be important that the code works with the new part for the AEV.

 

Table 03: Overview of Upcoming Labs

Labs Goals
Lab 10A Retrieve the payload successfully at least 3 times out of 5.
Lab 10B Reduce power consumption by increasing coasting distance but able to complete the objective at the same time.
Lab 10C Debug for a more consistent performance.

 

Lab 08 Progress Report (03/24/17)

Situation

The first performance test focused on evaluating the design for the AEV by comparing two designs from the team and determining which design used up less energy and would best complete the MCR. The importance of testing the design of the AEV once again was to evaluate how well it would perform on the actual track for the final test, as previous tests had been run on the straight track rather than the actual track on which the AEV would be tested in the end. Changing to a curving track may impact the performance of the AEV design, therefore, it was necessary to compare designs for the AEV in case the change in tracks brought up opportunities for improving the design.

 

Results & Analysis

For the first part of the first performance test, the AEV ran smoothly on the track, keeping its balance and refraining from swaying from side to side. Part of the reason for this, however, was due to the relatively slow speed of the AEV on the first runs. This was mainly due to the propeller design being used (EP-3030), which took up very large amounts of energy to get the AEV moving. After a few more test runs, the team decided on using a second AEV design, which used a different propeller design, EP-2510. This significantly changed the performance of the AEV for the remaining test runs. The motorspeed had to be decreased to prevent the AEV from falling off the track, and there was a significant increase in the AEV’s coasting distance after the brake command was executed, which led to a small change in balance when making the turn on the track. The change of propellers, however significantly impacted the timing for which the AEV started moving, with almost no delay in its execution of the code. Overall, it required much less power to move the same distance as the previous propellers, which is fulfilling the project’s constraints of low power consumption.

 

Takeaways

  1. Code – Coasting and braking distance must be considered when determining a proper speed
  2. Design- Take into consideration how each propeller design affects the amount of energy used by the AEV
  3. General – Take into consideration how the design of the AEV can affect the code, such as loose wheels resulting in slower speeds and shorter distances.

 

Weekly Goals

  1. Finish cutting the group’s AEV in SolidWorks
  2. Get the distance of the AEV’s travel corrected
  3. Slow the speed of the AEV down to allow for proper braking and coasting

 

Weekly Schedule

Table 01: Week 10 Schedule

Task Teammate(s) Start Date Due Date Time Needed
Finish PDR (general setup) all been in progress March 26 2-3 hours per person
Executive Summary (PDR) Ameeya been in progress March 26 2 hour
Results & Discussion (PDR) Brisa been in progress March 26 2 hours
Conclusion & Recommendations (PDR) Teck Yang been in progress March 26 2 hours
Introduction & Methodology (PDR) Justin been in progress March 26 2 hours
Finish Solidworks for Appendix (PDR) Brisa & Justin been in progress March 26 2-3 hours
Finish Progress Report 09 all March 22 March 24 1-2 hours
Team Meeting all March 26 March 26 TBD

 

Appendix A

Team Meeting Notes

Date: March 22, 2017

Time: 2:00 pm

Members Present:Justin, Teck Yang, Brisa, Ameeya

Topics Discussed: PDR progress, upcoming performance tests  

Objective:

Evaluate where we are as a group and determine how time will be spent in the next lab.

 

To Do/ Action Items:

  • Evaluate code and determine what needs to be changed and how it will be debugged for the next performance testing (for Friday, March 24)
  • Finish PDR (by Sunday, March 26)
  • Determine any final changes to the design (during team meeting, March 22)

 

Decisions:

The team has come up with a way to debug the code for the next performance test on Friday by making small changes to the code that was tested for the first performance test. The progress of the AEV has also been evaluated and it has been determined that the overall current design of the AEV works well, therefore the code is the next big step for improving the AEV’s performance. Along with looking ahead, a code algorithm has been written out to help in evaluating the code itself in the next performance test.

 

Reflections:

The group need to focus on finalizing the AEV overall (code and design) and start preparing for final presentations and data collection (evaluating the data collected). It’s also important to keep in mind the team’s upcoming schedule in other classes when meeting as midterms and finals will start coming up later.

 

 

Appendix B

Performance Test Utilized Code

celerate(4,0,30,0.5); //Accelerate all motors from 0% to 30% in 0.5 seconds.

goToRelativePosition(100);

brake(4); //Brake all motors for 10 seconds when it read 110 marks.

goFor(10);

int absolutePosition = getVehiclePostion(); //stores AEV’s absolute position into an integer.

 

//if AEV overshoots the second sensor

if (absolutePosition > 409) {

reverse(4); //reverse all motors

celerate(4,0,13,0.1); //accelerate all motors from 0% to 13% power in 0.1 seconds.

goToAbsolutePosition(400);

brake(4); //brakes all motors for 7 seconds when AEV reaches the middle of two sensors.

goFor(7);

}

//if AEV didn’t reach the first sensor

else if (absolutePosition < 392) {

celerate(4,0,13,0.1); //accelerate all motors from 0% to13% power in 0.1 seconds.

goToAbsolutePosition(400);

brake(4); //brakes all motors for 7 seconds when AEV reaches the middle of two sensors.

goFor(7);

}

//if AEV is in between the two sensors

else{

brake(4);// brakes all motors for 7 seocnds

goFor(7);

}

 

celerate (4,0,30,0.5); //accelerate all motors from 0% to 30% power in 0.5 seconds.

goToRelativePosition(125);

brake(4); //brake all motors for 15 seconds when it read 125 marks.

goFor(15);

 

reverse(4); //reverse all motors

celerate (4,0,30,0.5);//accelerate all motors from 0% to 30% power in 0.5 seconds.

goToRelativePosition(-125);

brake(4); //brake all motos for 10 seconds when it move 125 marks backwards

goFor(10);

 

//if AEV overshoots the second sensor

if (absolutePosition < 432) {

reverse(4); // reverse all motors

celerate(4,0,10,0.5); //accelerate all motors from 0% to 10% power in 0.5 seconds.

goToAbsolutePosition(440);

brake(4); //brake all motors for 7 seconds when it is between two sensors

goFor(7);

}

//if AEV didn’t reach the first sensor

else if (absolutePosition > 440){

celerate (4,0,10,0.5); //accelerate all motors from 0% to 10% power in 0.5 seconds

goToAbsolutePosition(440);

brake(4); //brake all motors for 7 seconds when it is between two sensors.

goFor(7);

//if AEV is between two sensors

else {

brake(4);

goFor(7);

}

 

celerate (4,0,30,0.5); //accelerate all motors from 0% to 30% power.

goToRelativePosition(-125);

brake(4); //brake all motors for 15 seconds when it move 125 marks backwards.

goFor(15);

Lab 07 Progress Report (03/03/17)

Situation

The group investigated different potential designs for their AEV. Testing different AEV designs was important, because it was essential for the group to check what factors are affecting the AEV’s performance and efficiency. These items were completed by testing design that had different wing spans, center of masses, and location of propellers than the group’s initial design.

 

Results & Analysis

In the previous test, design B had better balance due to its small wingspan, and therefore traveled further than design A (the reference design). From this, the team deduced that balance played a much relevant role in increasing the energy efficiency than previously thought.To accommodate this new knowledge, the team decided to increase the weight of the balance criteria by 5% by reducing the quality and aesthetics by 5% for the upcoming labs.

 

Takeaways

  1. Code – It is important to make sure the code performs the necessary objectives well.  
  2. Design- Simplifying the design of the AEV would help reduce weight and lower energy usage.
  3. Design – Make the front of the AEV narrow and sharp for improved aerodynamics.
  4. General – Ensure to keep documenting the process for the AEV.

 

Weekly Goals

  1. Finish Lab 8 Progress Report during team meeting on Wednesday, March 8. Each member being responsible for their part.
  2. Delegate tasks for PDR before Friday to allow each person to work on their part during spring break.
  3. Prepare a full track code for testing during lab on Friday, March 10.
  4. Decide on the base with the best weight distribution/balance to be tested on Friday.   

 

Weekly Schedule

Table 01: Week 08 – 09 Schedule

Task Teammate(s) Start Date Due Date Time Needed
Delegate PDR Parts Brisa 3/6/17 3/8/17 1 hr
Write Full Code for AEV Brisa 3/8/17 3/10/17 1.5 hr
Prepare for Extra Credit Video Recording Teck Yang 3/6/17 After Spring Break (specific date TBD) 1 hr
Finish Writing Progress Report 08 All Members 3/8/17 3/9/17 1.5 hr

 

 

Appendix A

Table 02: Concept Screening and Scoring

A Reference Design B
Success Criteria Weight Rating Weighted Score Rating Weighted Score
Balance 20% 6 1.2 4 0.8
Minimal Blockage 10% 4 0.4 3 0.3
Center-of-Gravity Location 10% 6 0.6 5 0.5
Maintenance 10% 4 0.4 3 0.3
Quality & Aesthetics 15% 3 0.45 4 0.6
Weight 5% 6 0.3 6 0.3
Code Performance 30% 3 0.3 3 0.3
Total Score 100% 3.65 3.1
Continue? Yes

 

Descriptions of the Criteria Choices

  • Balance: The AEV’s weight is distributed evenly allowing it to remain upright and stable.
  • Minimal Blockage: The AEV has nothing obstructing its movement, which allows it to move easily.
  • Center-of-Gravity Location: This point will allow the weight of the AEV to be distributed properly for better stability.
  • Maintenance: The condition of the AEV will continue to be preserved throughout each run (cleanliness of the design)
  • Quality & Aesthetics: The presentation and condition of the AEV is engaging and attractive.
  • Cost: The amount of money spent to design the AEV is an affordable price range.
  • Code Performance: The AEV executes the tasks needed to be accomplished properly.

 

Appendix B

Tested Lab Code

// Accelerate all motors from start to 25% in 3 seconds.

celerate(4,0,25,3);

// Run all motors at a constant speed (25% power) for 1 second.

motorspeed(4,25);

gofor(1);

// Run all motors at 20% power for 2 seconds.

motorspeed(4,20);

gofor(2);

// Reverse all motors.

reverse(4);

// Run all motors at a constant speed (25% power) for 2 second.

motorspeed(4,25);

gofor(2);

// Brake all motors.

brake(4);

brake(4);

Appendix C

Team Meeting Notes

Date: 03/08/17

Time: 1:55 pm

Members Present: Teck Yang, Justin, Brisa, Ameeya

Topics Discussed: Upcoming lab 08 & Plans for Spring Break

Objective:

Define what needs to get done before the upcoming lab as well as what needs to be done during spring break so as to not fall behind once classes start again.

 

To Do/ Action Items:

  • Have two design concepts ready to be tested for lab 08 and compare these two designs to the reference AEV design.
  • Start planning for the PDR due in lab 09.
  • Finish AEV code.

 

Decisions:

  • Use the results of this upcoming lab to finalise on the design so we can start focusing on the coding during next lab.The data collection is crucial to determine whether the design is focusing on the constraints of low energy consumption and high energy efficiency.
  • The team will meet up over spring break to discuss and complete the PDR by the end of the break.
  • Make the wing span of the propeller arms shorter to improve the overall balance.

 

Reflections:

  • Every team member should start taking an active role in both the design and coding process to get the AEV ready for performance tests in the upcoming labs.

 

Lab 06 Progress Report (02/24/17)

Situation

The lab served as a “halfway” checkpoint between the introductory and final labs. The group used the lab to re-group and check over our previous work for the design project. The completion of  checkpoint was important because it was a good opportunity for the group to check their work and make changes and upgrades. The method used to complete reworking the previous tasks on previous labs and running test to make sure that the AEV running properly.

 

Results & Analysis

During the lab test run of the AEV, there were several components of the design that were evaluated, one of the main parts being the balance of the vehicle. Individually, the design demonstrated to need improvement in its balance and center of gravity. The AEV seemed to sway from side to side quite a bit, meaning that energy might be lost, as it hinders the AEV from performing adequately. In comparison to the reference design, the balance score was lower for the design tested than that of the reference design. The loss of balance may be due to the placement of the wings, as the wings were placed in a more laid out design, this will most likely lead the team to changing the wings closer in to the body in order to restore balance as had been done for the first (reference) design.

Another area of low scoring was the maintenance of the vehicle. Some of the wires and the battery were not as well adjusted to the vehicle and could also be a source for the lack of balance. This will be addressed by the team for later designs by ensuring that each component of the AEV is compact and tightly placed on the vehicle.

Lastly, the aesthetics of the second design seemed to be better than that of the reference vehicle. It seemed more creative and thought out. This will most likely lead to the team adjusting the faulty areas, being balance and maintenance, of the second design to mirror that of the reference design while still keeping the creativity of design B. The remaining areas of evaluation demonstrated to be the same for both designs, therefore, other ideas might be tried out to improve those areas.

 

Takeaways

  1. General – The group needs to work on there time management during labs to prevent rushing at the end.
  2. AEV Performance – The group needs to determine why the AEV needs a high power percentage in order to move.
  3. AEV Design – The group needs to ensure that the AEV design that will be tested is designed before lab in order to save time.

 

 

 

Weekly Goals

  1. Get PDR presentation worksheet finished on Wednesday’s team meeting by 5pm.
  2. Finish lab 06 progress report before next team meeting on Wednesday, February 22. Each person being responsible for their individual component(s).
  3. Have at least 5 of the lab posts posted on the portfolio by Friday’s lab on February 25.

 

Weekly Schedule

Table 6.1: Week 7 Schedule

Task Teammate(s) Start Date Due Date Time Needed
PDR Presentation wksht All February 22 (Wednesday) February 25 (Friday) 1 hour
Portfolio Jake & Brisa Already Started February 25 (Friday – Part of it) Indefinite
Video Part 1 Jake Already Started March 3 (Friday) 3 hours
Lab 06 Progress Report All (each their individually assigned parts) February 19 (Sunday) February 22 (Wednesday) 2 hours
Team Meeting All February 22

@ 4:00 pm (Wednesday)

February 22 (Wednesday) 1 hour

 

Appendix A

Lab 05 Code

// Accelerate all motors from start to 25% in 3 seconds.

celerate(4,0,25,3);

// Run all motors at a constant speed (25% power) for 1 second.

motorspeed(4,25);

gofor(1);

// Run all motors at 20% power for 2 seconds.

motorspeed(4,20);

gofor(2);

// Reverse all motors.

reverse(4);

// Run all motors at a constant speed (25% power) for 2 second.

motorspeed(4,25);

gofor(2);

// Brake all motors.

brake(4);

brake(4);

 

Appendix B

Team Meeting Notes

Date: February 19, 2017

Time: 6:00 pm

Members Present: Jake, Ameeya, Brisa, Justin

Topics Discussed: Due Dates, Upcoming Labs, Extra Credit

Objective:

Begin to work on and complete the majority of the Lab 6 Progress Report and start the Portfolio.

 

To Do/ Action Items:

The following are what needs to be done/considered for the upcoming 2 weeks:

  • PDR Presentation worksheet (Due Friday, February 25)
  • Portfolio (checked Friday, February 25)
  • Lab 06 Progress Report (Due Friday, February 25)
  • Video Part 1 (Due Friday, March 3)
  • Oral Presentation (Friday, March 3)

 

Decisions:

The group’s schedule has been created, which prioritizes the to do items by their due date and importance. Each member’s individual role has been discussed as follows: Brisa, Justin, and Ameeya are responsible for finishing the lab 06 progress report. Jake will focus on putting the lab report data/posts on the portfolio. The team will all work on completing the PDR worksheet by next meeting.

 

Reflections:

We need to define the roles in future labs and components of the presentation as we are getting closer to major due dates.

 

Appendix C

Table 6.2 Concept Screening and Scoring

A Reference Design B
Success Criteria Weight Rating Weighted Score Rating Weighted Score
Balance 20% 6 1.2 4 0.8
Minimal Blockage 10% 4 0.4 3 0.3
Center-of-Gravity Location 10% 6 0.6 5 0.5
Maintenance 10% 4 0.4 3 0.3
Quality & Aesthetics 15% 3 0.45 4 0.6
Weight 5% 6 0.3 6 0.3
Code Performance 30% 3 0.3 3 0.3
Total Score 100% 3.65 3.1
Continue? Yes

 

Descriptions of the Criteria Choices

  • Balance: The AEV’s weight is distributed evenly allowing it to remain upright and stable.
  • Minimal Blockage: The AEV has nothing obstructing its movement, which allows it to move easily.
  • Center-of-Gravity Location: This point will allow the weight of the AEV to be distributed properly for better stability.
  • Maintenance: The condition of the AEV will continue to be preserved throughout each run (cleanliness of the design)
  • Quality & Aesthetics: The presentation and condition of the AEV is engaging and attractive.
  • Cost: The amount of money spent to design the AEV is an affordable price range.
  • Code Performance: The AEV executes the tasks needed to be accomplished properly.

Lab 05 Progress Report (02/17/17)

Situation

Last week, the group investigated the energy consumption of the AEV.  The completion of this investigation was important because it was necessary for the group to obtain data that would help in managing the power efficiency of the AEV. The group obtain this by running the data from the AEV test runs through MATLAB.

 

Results & Analysis

Based on the data portrayed in table 5.1 below, it should be noted that a greater amount of energy was used up per distance run in phase 1 than in phase 2. This change in energy correlates to the change in power. It seems that, once the power was increased, less energy was used up per distance. The team can take this information to evaluate future plans for the code of the AEV, as using up a small percentage of power may cause for the AEV to require a lot more energy in order to move, whereas a higher percentage power, while it may take up more energy at first, will probably make the AEV more energy efficient in the long run as it gains momentum and speed.

 

Phase 3 should also be taken into consideration, as that was the brake phase of the code. While the energy used to break the AEV was not as significant as in phase 1 and 2, the qualitative component of the code should be taken into account. If more power is used to have results similar to that of phase 2, the AEV will have a greater speed at the end of the phase and a greater amount of time, distance, and energy will be needed to stop the AEV. Therefore, the timing of the brake phase should be very well thought out within the code.

 

Table 5.1 (Phase Calculations)

Phase Arduino Code Time(s) Distance (m) Energy (J)
1 Start with 60% Power 2.161 0.5332 27.0937
2 Increased to 70% Power-

Break

3.962 3.9556 47.648
3 Break 5.277 9.0644 0.364
Total Energy (J) 75.106

 

Takeaways

  1. General – Multiple parts of the AEV design process needs to be done concurrently to obtain a consistent progress.
  2. Specific – The group was able to calculate the energy consumption of the current AEV prototype design.
  3. Specific – Modifications need to be made to the code in order to stop the AEV precisely, while also being energy efficient.

 

Weekly Goals

  1. Have the front part for the AEV designed so that it could be 3D printed afterwards. It will not have to be 3D printed at the moment, but it should be designed by Sunday’s meeting, February 19.
  2. Portfolio should be started by Sunday, February 19, the website should be created, and prepared for information to be added into it.

 

Weekly Schedule

Table 5.2: Week 6 Schedule

Task Teammate(s) Start Date Due Date Time Needed
Finish Lab Report Ameeya, Brisa, Teck Yang, and Justin (each person responsible for their assigned part written in team meeting notes) February 15 February 17 4 hours
Start Portfolio Brisa & Teck Yang February 16 February 19 1-2 hours
Individual Calculations Ameeya, Brisa,Teck Yang, and Justin (individually) February 15 February 17 1 hour
Team Meeting All Members February 19 February 19 1.5 hours

Appendix A

Graph 5.1 Time vs Power

 

Table 5.1 (Phase Calculations)

Phase Arduino Code Time(s) Distance (m) Energy (J)
1 Start with 60% Power 2.161 0.5332 27.0937
2 Increased to 70% Power 3.962 3.9556 47.648
3 Break 5.277 9.0644 0.364
Total Energy (J) 75.106

 

Graph 5.2-5.3 EEPROM Graphs for Three Different Trials of the same Code

Appendix B

Team Meeting Notes

Date: February 25, 2017

Time: 1:55pm

Topics Discussed: Lab Progress Report + AEV documents

Objective:

Figure out what needs to get done and delegate.

To Do/ Action Items:

Portfolio needs to be started. We need to finish Lab Report 5. Prepare for Lab 05. Make a 3D draft of the AEV of both discussed designs.

Decisions:

Brisa will start on the Portfolio, and Jake will continue adding different types of documentations onto the portfolio.

Reflections:

We need to have a full team meeting where we talk about our goals and future actions of the project (not focus on the solely on the lab report).

 

Appendix C

Arduino Code

//Run all motors at 60% power for 2 seconds.

motorSpeed(4,60);

goFor(2);

//Reverse all motors.

reverse(4);

//Run all motors at 70% power for 1 second.

motorSpeed(4,30);

goFor(1);

//Brake all motors.

brake(4);

Appendix D

Individual Components

Brisa Reyes – Individual Calculations

Time:

t=te1000=9601000=0.960 (seconds)

Current:

I=(Ie1024)Vr(1 amp0.185 v)=(1151024)2.46(10.185)=1.496 amps

Voltage:

V=(15Ve1024)=(155521024)=8.085 volts

Distance:

d=0.0124mark = 0.012415=0.186 m

Position:

s=0.0124pos=0.01245=0.062

Power:

P=VI=8.0851.496=12.075 watts

Energy:

E=Pj+Pj+12(tj+1tj)=(12.075+12.4952)(1.02-0.96)=0.737 J

 

Individual responsibilities: Prepare the Eportfolio

The team has gathered several forms of documenting the process of the creation of the AEV. My role now is to first start up the portfolio so the information and documents may be organized. This is to be done by February 19, when we will have our next meeting.

 

 

Lab 04 Progress Report (02/10/2017)

Situation

Last week the group took time to individually think of designs for the AEV. After this time they came together and presented their designs and the advantages and disadvantages of each to the group. This was done to help think through ideas that individually group members did not think of. After this the group discussed ways to combine the advantages of the different designs. This was done to create the best combination that made it lightweight and aerodynamic thus the most power efficient.      

  • Each team member brainstormed about different AEV designs. After brainstorming, the team shared and discuss the advantages and disadvantages of each design.
  • Each idea needs to be edited and evaluated by different people to get an objective and complete final result that’s acceptable by every team member.
  • Each team member shared about their ideas on how to address the power efficiency, light weight and consistency. Each idea is graded upon a rubric that the team prepared and the design that scored the highest is decided for now.  

 

Results & Analysis

The result from the discussion was that the group agreed that a lightweight AEV modeled after US fighter jets (F-22, F-35, F-117 and SR-71). This was decided because these airfoils were designed with aerodynamics, speed and the efficient use of power in mind. With these designs the AEV will be able to operate with less power consumption without losing performance.

  • The team came to a consensus that we want a lightweight AEV design
  • The team wanted a pointed AEV design, modeled after (inspired by) US fighter jets
  • These designs were built with aerodynamics and speed in mind, and therefore seemed like proper models to integrate into our own design.

 

Takeaways

  1. Technical: Take into consideration amount and type of materials provided
  2. Technical: ensure designs follow the guidelines and agree with the constraints
  3. General: Be able to develop a clean, concise sketch to properly portray the desired design

 

 

Weekly Goals

  1. Determine a process or set of codes that will be able to test the efficiency of the AEV designs.  
  2. Members will begin to draft and model their desired designs using SolidWorks.
  3. Each member will practice making the desired designs using Solidworks and learn to complete a basic sketch before next lab.
  4. By Friday (February 10), the data for the previous lab will have been calculated and plotted for Lab 03 Progress Report. At least 2 final sketches will have been formulated for the team to begin considering design

 

Weekly Schedule

Table 1: Week 6 Schedule

Task Teammate(s) Start Date Due Date Time Needed
Open Lab All 2/8/2017 2/8/2017 2hrs
Start Lab 5 All 2/10/2017 2/17/2017 4hrs
Group Meeting All 2/12/2017 2/12/2017 2hrs
Group Meeting All 2/15/2017 2/15/2017 1hr 30mins
Start Lab 6 All 2/17/2017 2/24/2017 4hrs

Lab 03 Lab Progress Report (02/03/2017)

Situation

This weeks lab focused on external sensors and system propulsion efficiency with regards to the AEV.  The importance of this lab was to familiarize ourselves with the AEV’s sensors and commands that would allow for certain sensors to work and understand how the roles these sensors and commands played in making the AEV move. This was done by creating a code for the program to test out the behavior of the external sensors. The second half of the lab focused on using wind tunnel equipment to test out how propulsion efficiency works with different motor configurations. Looking into the different types of configuration for propulsion (push and pull), and the overall propulsion efficiency, gave the team some more background on which type of propulsion would be best and more efficient for the AEV. The team will utilize the knowledge gained in this lab to construct a preliminary code to complete the scenario stated in the Mission Concept Review by focusing on the external sensors and system propulsion efficiency.

 

Results & Analysis

The behavior of the arduino on the track was a combination of expected and unexpected behaviors. The AEV seemed to run smoothly through the track and without complications. The problem, however, was that it refused to move when the motor speed was set to anything less than 60%. Once it started its journey, another problem was encountered when the AEV did not stop at the gate as the code had intended for it to do. Due to the time constraint, there wasn’t enough time to completely troubleshoot the code to see if the code was the problem. By looking at the different propeller results, we decided that we should use the propeller type EP-2510 in our design. The results show a noticeable difference between the propellers at different configurations, especially in the pusher configuration of propeller type EP-3030. It performed much less efficiently than its puller counterpart : generating only 33.5% of puller configuration’s RPM and consuming 36% more current at the same Arduino power setting. While both configurations of propeller type EP-2510 perform roughly the same as the puller configuration of propeller type EP-3030 and more consistent overall. Since energy management, operational efficiency and operational consistency is being prioritized in the AEV tasks, we decided to use the propeller type EP-2510.

 

Takeaways

  1. Technical – Importance of troubleshooting, having a well developed Arduino code
  2. Technical – Process of data collection with propellers
  3. General – Problem Solving Skills are crucial as well as patience when something doesn’t workout at first.
  4. General – The importance of reaching out for further guidance when something isn’t very clear
  5. General – Better task delegation was practiced during this lab (To make better use of lab time, two teammates worked on installing the reflectance sensor, one teammate collected the wind tunnel data acquisition, one worked on the inside track code, enabling the team to accomplish much more in a short time)
  6. General – Prepare for unexpected delays or problems

 

Weekly Goals

  1. Finish the wind tunnel calculations and analysis by Thursday to form a conclusion about which type of configuration (push or pull) is most efficient for our project.
  2. Troubleshoot the code from last lab to determine the following: why the AEV did not brake successfully, why the AEV only moved when the speed was set up at 60% and not when it was set at 25%
  3. Read up on next week’s lab manual (pg 51-55) before Friday’s lab to be better prepared.

 

Weekly Schedule

Table 1: Week 5 Schedule

Task Teammate(s) Start Date Due Date Time Needed
Finish Calculations All members February 1 February 3 3 hours
Team Meeting All members February 1 February 3 1 hour
Finish Lab Report All members responsible February 1 February 2 2 hours

 

Appendix A

Arduino Code

Inside Track Code

//Run all motors at 25% power for 2 seconds.

motorSpeed(4,25);

goFor(2);

//Run all motors at 20% and travel a distance of 13.5 feet from the start.

motorSpeed(4,20);

goToAbsolutePosition(332);

//Reverse all motors.

reverse(4);

//Run all motors at 30% power for 1 second.

motorSpeed(4,30);

goFor(1);

//Brake all motors.

brake(4);

 

 

Appendix B

Team Meeting Notes (20 min)

Date: 2/1/17

Time: 2pm-4pm

Members Present:  Brisa Reyes, Teck Yang Koh, Justin Western, Ameeya Watkins

Topics Discussed: Corrections to the code

Objective: To discuss what went wrong or incorrectly in the coding of the AEV

To Do/ Action Items: Perform tests on the Arduino code

Decisions: Do further testing using different functions and test whether the desired result could be obtained.

Reflections: Further studies into the Arduino code need to be made to obtain a consistent performance

 

 

Appendix C

INDIVIDUAL SAMPLE CALCULATIONS – Brisa Reyes

Propeller : EP-2510 , Puller Configuration

Voltage : 7.4 volts

Velocity : 2.8 m/s

Thrust : 181.7

RPM : 3473

Power Setting : 15%

Current : 0.21 Amps

 

Calibrated Thrust (g)

Tc= 0.411 (T-T0) = 0.411 (181.7 (g) – 165.3 (g)) = 6.740 (g)

Power Input

Pin= V I(P% 100)=7.4(volts)0.21(amps)(15/100) = 0.233 (watts)

Power Output

Pout=Tcv=6.740 (g) (1 / 101.97 (g)) 2.8 (m/s)=0.185 (watts) (1/745.7) = 0.000258 (hp)

Propulsion Efficiency

Propulsion Efficiency = PoutPin100=(0.185 (watts) / 0.233 (watts) )100 = 79.45 %

Propeller Advance Ratio

Propeller Advance Ratio = v(RPM/60)D=(2.8 (m/s))/((3473/60)0.1)=0.484

 

 

Appendix D

Propeller Data

Lab 02 Progress Report (1/27/2017)

Situation

This week, the group worked on setting up the coding for basic commands for the AEV and uploading the code onto the AEV controller.

The importance of this being completed was for the group to become familiarized with the Arduino coding basics and learning how to upload several codes into the AEV. This was done by having the group work on making a code that required the propellers to work properly.

 

Results & Analysis

The group results came from the testing of the external sensors and system analysis, there were no quantitative results to be analyzed, as it was all mostly testing of performance of the arduino coding. Once the code for the first scenario was ready to be tested, the electric motors did start turning with what seemed no resistance or hinderance, but this only lasted for barely a couple seconds.The group then sought to define the reason for the motor’s lack of performance. The code was thoroughly checked to ensure there were no errors with the coding itself. After having had it verified by a TA that there was no problem with the code or the uploading of the code, it was concluded that the error must have come from the connection of the motors to the computer. Due to the time constraint, the code was unable to be tested on a different computer to verify the root of the error, and another time was scheduled for the group to test out the coding once again.

While the code was not put into practice during the lab session, there were several components from the code itself that could be identified. It was noted that, with the possible commands introduced during the lab, there are several limitation imposed by the coding. An example of this was noticing that after applying the “brake(m)” command, the AEV would not stop immediately; due to the AEV’s inertia, it would continue to move for some distance before friction slows it down to a complete stop, therefore limiting the precision of the braking time for the AEV.

Due to the problems with the computer, the group did need to reach out for additional guidance on how the problem could be resolved. Despite the aid received, the group was unable to fix the problem. In this case the group would recommend some more direct guidance when problems such as this are encountered in order to make the lab a better experience.

 

Takeaways

  1. Technical – Importance of coding, coding is responsible for main functions of the AEV and there are several components that have to be taken into account for each command we want the AEV to follow
  2. General – It is important to prepare well for the lab beforehand to not lose time in the lab trying to figure out what the next step is
  3. General – Time management before and during the lab are vital.

 

Weekly Goals

  1. Read the lab manual pages thirty-two through fifty-one by Friday, before the start of the second lab.
  2. Get through the entire lab efficiently with minimum wasted time, check over all work done, and resolve errors.
  3. Finish testing the code from first lab before the start of the second lab within a one hour time period.
  4. Before the start of the second lab, assemble the AEV using the sample model that will be able to fit onto the tracks.

 

Weekly Schedule

Table 5.2: Week 2 Schedule

Task Teammate(s) Start Date Due Date Time Needed
Work on AEV assembly Team January 18 January 20 1 hour
Finish reading Lab Manual pages 32-51 Team January 18 January 20 1 hour
Redo Lab 01 Team January 20 January 20 1 hour
Edit/finish coding for Lab 01 Team January 18 January 20 2 hours

 

Appendix A

Arduino Code

Scenario 1

celerate(1,0,15,2.5); // Accelerates motor 1 from 0% to 15% power in 2.5 seconds

motorSpeed(1,15); //runs motor 1 at 15% power

goFor(1); // runs motor for 1 second

brake(1); // brakes motor 1

celerate(2,0,27,4); // Accelerates motor 2 from 0% to 27% power in 4 seconds

motorSpeed(2,27); //runs motor 2 at 27% power

goFor(2.7); // runs motor 2 for 2.7 seconds

celerate(2,27,15,1); // deccelerates motor 2 from 27% to 15% power in 1 second

brake(2); // brakes motor

reverse(2); // reverses motor

celerate(4,0,31,2); // accelerates both motors from start to 31 percent power in 2 seconds

brake(2); // brakes motor two

motorSpeed(1,35); // runs motor 1 at 35 percent power

goFor(3); // runs motor for 3 seconds at initial power

brake(4); // brakes all motors

goFor(1); //brake for 1 second

reverse(1); //reverse motor 1

celerate(1,0,19,2); //accelerate motor 1 from 0% to 19% power in 2 seconds

motorSpeed(2,35); //runs motor 2 at 35% power

motorSpeed(1,19); //runs motor 1 at 19% power

goFor(2); //run motors for 2 seconds

motorSpeed(4,19); //runs all motor at 19% power

goFor(2); //runs motors for 2 seconds

celerate(4,19,0,3); //decelerate all motor from 19% to 0% power in 3 seconds

brake(4); //brake all motors

 

Scenario 2

reverse(4); //reverse all motors

motorSpeed(4,25); //runs all motor at 25% power

goFor(0.5); //runs motor for 0.5 seconds at initial power

brake(4); //brakes all motors

goFor(0.1); //brake for 0.1 seconds

motorSpeed(4,25); //runs all motor at 25% power

goFor(0.5); //runs motor for 0.5 seconds at initial power

brake(4); //brakes all motors

goFor(0.1); //brake for 0.1 seconds

motorSpeed(4,15); //runs all motor at 15% power

goFor(0.3); //run motor for 0.3 seconds at initial power

brake(4); //brakes all motors

goFor(0.05); //brake for 0.05 seconds

motorSpeed(4,40); //runs all motor at 40% power

goFor(0.3); //brake for 0.3 seconds

motorSpeed(4,25); //runs all motor at 25% power

goFor(0.5); //run motor for 0.5 seconds at initial power

motorSpeed(4,15); //runs all motor at 15% power

goFor(0.3); //run motor for 0.3 seconds at initial power

brake(4); //brakes all motors

goFor(0.05); //brake for 0.05 seconds

motorSpeed(4,40); //runs all motor at 40% power

goFor(0.3); //run motor for 0.3 seconds at initial power

motorSpeed(4,25); //runs all motor at 25% power

goFor(0.5); //run motor for 0.5 seconds at initial power

brake(4); //brakes all motors

goFor(0.5); //brake for 0.5 seconds

motorSpeed(4,55); //runs all motor at 55% power

goFor(0.5); //run motor for 0.5 seconds at initial power

brake(4); //brakes all motors

goFor(0.1); //brake for 0.1 seconds

 

Appendix B

Team Meeting Notes

  • Weekly Meetings (Date and Time): Sunday with varying times and Monday at 5pm
  • Other Possible Meeting Times: Wednesday at 4pm
  • Preferred Method of Communication: GroupMe for general communication, email (if we have documents to share, and Google Drive for projects sharing and participation
  • Individual Emails:
      • Ameeya – watkins.624
      • Jake – koh.114
      • Justin – Western.18
      • Brisa – reyesnavarro.1
  • Structure of the team meetings:

1) Status Report: The group goes over a short briefing regarding the progress of the project that they are working on.

2) Objectives: The group has a discussion about the upcoming lab objectives.

3) Brainstorming: The group talk about numerous ideas, determine the positives and negatives of each of them.

4) Task Delegation : The group discusses what task are in the future, what preparation they require, and what task should be completed before the next meeting.

 

Group K Portfolio (Team Contact Information)

Group K – Brisa Reyes, Teck Yang Koh, Justin Western, Ameeya Watkins

Instructor – Dr. Parris, GTA – Sheena Marston

This portfolio is a collection of documentations of our ENGR 1182.01 Advance Energy Vehicle project.

 

{: Team Members :}

 

[Brisa Reyes]

[reyesnavarro.1@osu.edu]

 

[Teck Yang Koh]

[koh.114@osu.edu]

[Ameeya Watkins]

[watkins.624@osu.edu]

[Justin Western]

[western.18@osu.edu]

 

 

List of Progress Reports

Lab 02 (01/27/17)

Lab 03 (02/03/17)

Lab 04 (02/10/17)

Lab 05 (02/17/17)

Lab 06 (02/24/17)

Lab 07 (03/03/17)

Lab 08 (03/27/17)

Lab 09 (04/03/17)