CDR Report | ENGR 1182 Spring 2017

Executive Summary

The Advanced Energy Vehicle (AEV) project emphasis on project management and teamwork, design process/cycle and project documentation. The project’s real objective is to prepare the students for the style of work they will have when they become engineers or when they work as a team in any company. The background of this project is solution to help the rebel alliance preparing for war with the galactic empire in remote planets. The situation given is the rebel alliance needs a transportation to pick up and deliver the cargo from the other side back to their base. Since the setting is in the remote planets, the condition given is limited of power sources. Hence, the transport should be energy efficient as well as capable of transferring the R2D2 from the other ends of the track to the base. The team was given several weeks to build an AEV system that can complete the task; transporting the R2D2 with an energy efficient system. As the first step, the team had a brainstorm session where each one of the team member sketched their own ideas for the AEV design on sketch papers. All the sketches were then being considered in a discussion to decide which one of it the team want to go forward with the project. The team chose one design and built the AEV system according to the chosen sketch. To make things easier, all the sketches were made only consists the parts that provided in the lab kit. The first three weeks, the team try to get the coding that compatible with the first AEV design and did several test runs during the labs to collect data. The results from the runs were then taken into further consideration. Feeling unsatisfied with the results, the team then changed to a new design where the idea for the design came from the combination of several elements that the team had in the sketches. The idea was chosen after got every team member’s approval. The new design then being tested during the next labs and the data was collected for comparison with the first design’s data. Both of the data were compared using the scoring table where the score given for every aspects came from the discussion among the team members. The comparison data was being considered in final decision making for the design. The team realized there were some flaws in the previous two design and decided to change to a new design which the objectives of this design is to overcome those flaws. Using the third design (final team design), the team then go forward with the coding process to complete the task. There were many troubles the team had to encountered during the coding process. One of them is to find the perfect marks for the AEV to stop or move during the run. The team did several run to test which coding the team want to use by collecting data from two codes; “back thrust” command or using the coasting effect come from the momentum of the AEV. After several tries and compared both result, the team decided to use the coding that utilize the coasting effect because this coding has more energy efficiency than the other one. The only thing need to be done for this coding was to find the perfect marks to make the motor stop so that the AEV will glide and stop exactly before the gate which is also one of the difficulties the team encountered. The team found the perfect coding that can complete the task as well as use less energy. The final coding then was set for final test run associated with the final design and the data was collected using Matlab and Excel. The team was able to complete the project while meeting all the requirement in time. Even though the team’s final result was not the best in class, the project really taught many important lessons to all the team members.

Introduction

The Advanced Energy Vehicle (as known as the AEV) is a small vehicles[machines] that used electricity as its power source and run on a mini track system on the laboratory ceiling built specifically for this kind of vehicles. The AEV system basically are made of components in a lab kit given earlier in the project which includes prefabricated PVC sheet structures, monorail wheels, electric motors, propellers and an in-house built AEV- Autonomous Control System.

The AEV design project is a team assignment given to the students as a mean to make them prepares for any kind of team project they will have when they become engineers. One of the objectives of the project is to introduce the students with managing projects and work as a team. The students learned how to work as one system to complete the task given from the scratches; from the design process until the final product presentation and documentation. The team is allowed to add more parts other than what was provided in the lab kit since the final design is not specified; the most important thing in this project is the system can complete the task.

The task is to build a monorail system that can transport the R2D2 units from the other ends back to the base (starting points) as a preparation of the rebel alliance for war with the galactic empire on the remote planets. Energy efficient system is needed as power is very limited in the remote planets. Hence, the AEV must be able pick up and deliver the R2D2 (load) while meeting the operational requirements, design constraints and minimizing the energy/mass ratio.

Experiment Methodology

AEV Operational Requirements

The AEV is supposed to complete the following scenario while optimizing the criteria in the Mission Concept Review in order to complete the mission. The following scenario is listed below and in the figure 1 below show the AEV track layout.

The AEV will start at the Drop-off area and it will stop at the first gate
The AEV must not gets too close or too far from the gate to activate the sensor. It takes the gate 7.0 seconds to open when the sensor has been activated.
After passing through the first gate, the AEV will navigate to the cargo area.
The AEV must stop at the cargo area and pick up an R2-D2 and wait 5.0 seconds to verify cargo is all loaded.
Then, the AEV need to travel back and stop at the previous gate.
The AEV must not gets too close or too far from the gate to activate the sensor. It takes the gate 7.0 seconds to open when the sensor has been activated.
Finally, the AEV navigate to the drop-off area after passing through the gate. Both wheels of the AEV must be between Mark 2 and the start point to successfully complete the mission objective. Lastly, the team must make sure that the AEV must complete the full cycle of the scenario within 2.5 minutes.

Figure 1: AEV Track Layout

Lab Equipment

In Figures 2,3,4 and 5 below shows the lab equipment that is being used in the lab to carry out the Mission Concept Review(MCR).

Two electric motors
AEV body structure and L-shaped arm
Two diameter propellers
Two reflective sensor
AEV wheels
AEV controller
Lithium battery

Figure 2: Body Structure, AEV wheels and reflective sensor.

Figure 3: Electric motor and diameter propellers.

Figure 4: Lithium Battery. Figure 5: L-Shaped Arm

AEV Controller

In figure 6 shows the AEV controller is a custom made controller and performance recorder system with an Arduino Nano microcontroller and two motor chips. The Arduino Nano is the one that being used to control motor speed, the time or distance and for recording the system data. The Arduino programming language is required to operate the AEV by using “Functions calls”.

Figure 6: AEV controller with Arduino Nano.

Function Calls

celerate(m,p1,p2,dt);

- Accelerates or decelerates motor(s) m from start speed (%) p1 to end speed (%) p2 over the duration of dt seconds.

▪ For example : celerate(4,0,20,2);

Will accelerate all motors from 0% to 45% full power in 2 seconds.

▪ For example: celerate(2,20,0,4);

Will decelerate motor 2 from 40% to 0% full power in 4 seconds.

- Four Arguments

▪ m: Motor number 1, 2, or 4 for all motors.

▪ p1: Start % speed (0% – 100%)

▪ p2: End % speed (0% – 100%)

▪ dt: Time span for celeration in seconds (1 – 10)

motorSpeed(m,p);

- Initializes motor(s) m at percent power p.

▪ For example: motorSpeed(4,30);

Sets all motors speed to 30% full power

- Two Arguments

▪ m: Motor number 1, 2, or 4 for all motors.

▪ p: % Speed (0 – 100)

goFor(dt);

- Runs the motor(s) at their initialized state for dt seconds.

▪ Example: goFor(2);

Runs the motor(s) at their initialized state for 2 seconds

- One Argument

▪ dt: Time span in Seconds

brake(m);

- Brakes motor(s) m. NOTE: This does not brake the AEV.

▪ Example: brake(4);

Cuts the power from all motors.

- One Argument

▪ m: Motor number 1, 2, or 4 for all motors.

reverse(m);

- Reverses the polarity of motor(s) m.

▪ Example: reverse(2);

Reverse all motors;

- One Argument

▪ m: Motor number 1, 2, or 4 for all motors.

To complete the AEV for the final testing, the team need to create two separate code in order to determine the energy consumption in Performance Test 2. For the first code, the coding involved using “absolute position” command and back thrust part. For the second code, the team create a code using a “motorspeed” command at a certain time and a “brake” command . Then, the AEV was tested on the track to collect data. If the AEV have complete the full cycle on the track, the code was downloaded and then the data was analyzed using analysis tool from the MATLAB so that the team can determine the energy consumption for both of the coding. On the day of Final Testing, the team decided to combine the first and second code developed in Performance Test 2 instead of using the first code because of some problem occur at the end of Performance Test 3.

Results and Discussion

The team has gone through several processes before choosing the final AEV design for the project. The design was made based on the previous design by every team member. At first, the team combine the four design and decided to produce a design that has a good stability especially during the turns. So the chosen design was a bit heavy to make sure the AEV did not swaying during the run. However the stability does not guarantees an efficient AEV. From the system analysis lab in the beginning of the project, the AEV recorded 62.07 Joules. This amount is considered as high because the AEV only moves from the starting point and stops before the first gate. The energy consumed will be increased as the AEV move to cargo area and bring the R2-D2 back to the starting point. Moreover, the coding designed for the run is very simple as it only move and slide before stopping at the first gate. The additional coding to include back trust would also the energy consumption. So, the team discussed produce a design that is more efficient without neglecting the stability of the AEV. As a result the team came up with two design that can satisfy the efficiency and stability aspects (shown below).

Figure 1: The vertical design

Figure 2: The horizontal design

In the previous lab 4, the group came up with four designs that had their own spin off of the AEV vehicle. Adam’s design was inspired by a picture of a random spaceship from Google image. The Star Wars theme in this AEV project makes him thinks of a spaceship design. The design is simple and easy to built. The wing makes the AEV more stable and adds the elegance look to it. Since there is a balancing issue that the team faced earlier when moving the AEV, Adam thought the wing is a right approach to solve the problem. The weight of the design (body) is pretty light in order to increase the efficiency rate and make it move easily. The accessory for the design is the additional dots at the front of the AEV that makes it looks like front light. Izzat’s design is pretty similar to Adam’s design because both of them look like spaceship or rocket design. The design has the propeller at the back so that the AEV can have more power to move faster since the team already dealt with the starting projection several times. The 3D printed body was designed to reduce the drag force because more speed will be generated when the drag force is less. John’s design looks like a cylinder from the back. The reason is he want to have the AEV gain more stability and to prevent all the wires and stuffs like battery and Arduino to look messy. Though it might be heavier than others’ design, it is the most stable than others. Ahmad’s design looks like a boat. He thinks that it will be much easier to set up the stuffs on the AEV design plus it gives more stability than the old one. The 3D print design used also make the design lighter which makes the AEV faster to move. While discussing the pros and cons of each design, the group came to a conclusion about the design of the AEV as the team have a problem regarding the stability of reference AEV. So, the group mostly focused on the efficiency, stability and environmental of the AEV while creating the orthographic designs, the team thought it would be best if a design used had both an efficient body as well as a large base. The group designed a fifth design that incorporated all of the necessary improvements for the AEV.

As shown in the Figure 1 and 2 above, both design are actually made up from the same parts but only difference in the orientation. Both design had also been tested to make sure it satisfy the important aspects such as the balanced in turns, cost and also environmental. The designs were observed as it move on the track and the rating of every aspects will be given from the team’s discussion.

Figure 3: Concept Scoring and Screening Table

The figure above shows the comparison of the two designs which are the vertical and horizontal design. The comparison was made by calculating the total score of each design. The team found out that both of the design have a good centre of gravity in which allowed the AEV to have a good balance when turning; the AEV did not leaning to one side or swaying. The thing that really separated both of the design is the horizontal design have more efficiency and environmental than the vertical design. It is because the team notice that the horizontal design tend to give more thrust when using the same Arduino code. Assumption that the team made was the horizontal consume Even though the total score of both designs were same but the team decided to focus more on the efficiency compared to the stability of the AEV. So, the team had chosen the horizontal design as the final design because it is more efficient which also satisfy the environmental aspects more than vertical design. In term of cost, the team managed to cut the overall cost significantly. The cost was reduced by removing the unnecessary parts. The team also take account of the material needed, the possibility of the damage and the time to set up the design. Moreover, the cost of the project remain the same because both of the design are made up of the same parts. The team has tried to minimize the usage of any parts to make sure that the weight of the AEV is at optimum level. This also helps the team to satisfy the cost aspects because the minimum parts used will reduce the total cost of the project for the final design. The overall cost of the project is $149.85 (details in the appendix).

Table 1 show the data of wind tunnel 2 in push configuration with 3.0 inches of propeller diameter

Power Input (Watts)	Power Output (Watts)	Propulsion Efficiency	Advance Ratio
0	0	0	0
0.074	-0.009031478	-12.2047005	1.187890307
0.2442	-0.006773609	-2.77379558	0.736380898
0.4588	-0.003386804	-0.73818753	0.526061658
0.74	0.006773609	0.915352541	0.42325291
1.0878	0.018062957	1.660503475	0.347364804
1.5022	0.033868044	2.254562908	0.292248729
1.5096	0.080154371	5.309643005	0.225893894
2.2311	0.08241224	3.693794111	0.225893894
2.775	0.099346262	3.580045492	0.201197701
3.2153	0.109506676	3.405799633	0.183192722
3.6852	0.145632589	3.951823217	0.164372207

Figure 4: Graph Propulsion Efficiency Vs Advance Ratio

The figure 4 above show the propulsion efficiency against advance ratio It show that the lowest propulsion efficiency at power 10% which was -12%. On the other hand, it show the highest propulsion efficiency at power 40% which was 5.3%. This show that this configuration is not very suitable for the AEV because it decrease in the propulsion efficiency as the AEV maximized the power.

Table 2 show the data of wind tunnel 2 in pull configuration with 3.0 inches of propeller diameter

Power Input (Watts)	Power Output (Watts)	Propulsion Efficiency	Advance Ratio
0	0	0	0
0.1406	0.047415262	33.7235147	1.08340266
0.3108	0.065478218	21.0676378	0.72215015
0.5624	0.101604132	18.0661686	0.55787561
0.8695	0.139987915	16.0998177	0.4661151
1.2654	0.191918916	15.16666	0.40027676
1.7353	0.259655004	14.963119	0.35067988
2.2792	0.334164701	14.6614909	0.31473582
2.8305	0.399642919	14.1191634	0.28994272
3.478	0.476410486	13.6978288	0.2687705
4.2328	0.546404443	12.9088179	0.24878407
5.0172	0.640106032	12.7582323	0.2315887

Figure 5: Graph Propulsion Efficiency Vs Advance Ratio

As seen in figure 5 above, the lab team can concluded that increasing in percentage of arduino power makes the thrust scale reading increase too. The lowest propulsion efficiency at power 60% which was 12.7% while the highest propulsion efficiency at power 10% which was 33.7%. This configuration is suitable for the AEV because it increase the propulsion efficiency as the AEV used more power.

In Performance Test 2, the team created two codes to determine the energy consumption. For the coding 1(Appendix), the team have included the back thrust part to ensure the AEV stop instantly. It is because in the previous coding, the team used the brake command to stop the AEV, but the team found out that the AEV coasting before its stop. In order to pass through the first gate, the Arduino code must include a back thrust to prevent the AEV from coasting. The only issue for the coding 1 is the team has a trouble to code for stopping the AEV at the exact position. The team need to figure it out before the upcoming by asking help from the GTA or TA to figure out this problem. For the coding 2(Appendix), the team decided to change the coding by using the “motorSpeed” command at certain amount of time and used brake command to make the AEV glide. It is because the team want to reduce the usage of the energy used. The “motorSpeed” command will make the AEV have a speed for a few seconds and then it will glide The team concluded that the coding 2 have a slight higher energy efficiency than the coding 1. However, the team decided to use coding 1 because the coding 2 have a bigger issue on its consistency of run as it tend to stop before the gate and it takes much more time to complete one full cycle.

In Performance Test 3, the team tested the AEV on the track based on the two code from Performance Test 2 and analyzie the energy consumption by using the MATLAB analysis tools. Figure 4 below shows the supplied power to AEV using the coding part 1(appendix). The calculation was done by using AEV analysis tool in the matlab. In figure 1 below, the supplied power against time graph is classified into four phases. The phases were based on the arduino command.

Figure 6: Supplied Power to AEV (Coding 1)

Based on the figure above, there are two significant changes of power which is at the beginning of third phase and also the fourth phase. The supplied power is at its highest in phase third and fourth because the AEV require more power to move backward. As shown in the phase 1 above, the speed is set at 30% power. After the AEV reached the first gate, the power is decreasing. This is because the team used the brake command to cut the power supply. In phase 2, the power does not show any significant changes. At this point, the AEV is moving at same speed to the position before reaching the cargo area. In phase 3, the power shows a drastic increase due to the load that the AEV is carried over to the first gate. The AEV is still moving after the command for a few seconds and stop right before the gate. However, in the phase 4, the AEV did not stop at the drop-off. This clearly shows in the table above that there is a constant power supplied over certain amount of time. Thus, the team concluded that energy which is 609.56 joules, the code have some error at the end of fourth phase that makes the team unable to determine the energy efficiency. It is because the team have some trouble to determine the exact mark for fourth phases in the arduino.

Table 3 : Four Phases for the coding part 1

*Phase*	*Code*
1	reverse(4); motorSpeed(4,30); goToAbsolutePosition(260); reverse(4); celerate(4,30,0,3); brake(4); goFor(8);
2	reverse(4); motorSpeed(4,30); goToAbsolutePosition(690); reverse(4); celerate(4,30,0,3); brake(4); goFor(6);
3	motorSpeed(4,40); goToAbsolutePosition(300); reverse(4); celerate(4,30,0,3.5); brake(4); goFor(8);
4	reverse(4); motorSpeed(4,40); goToAbsolutePosition(60); reverse(4); celerate(4,30,0,3); brake(4); goFor(5);
Total Energy	609.56 Joules

Figure 7: Supplied Power to AEV (Coding 2)

Figure 7 above shows the supplied power to AEV using the coding part 2(appendix). For the coding part 2, the team did not have enough time to complete the full cycle based on the MCR. The team did only managed to code and record the AEV performance analysis from the start point to the cargo area. The team decided to change the coding from using the “gotoAbsolutePosition” command to using brake command. It is because the AEV still have inconsistent run to reached the first gate as sometimes the AEV might stop too soon or too late. The team concluded the coding part 2 have higher energy efficiency than the coding part 1 because the coding part 2 did not use a constant power energy consumption to reach the first gate, instead the AEV was glide to the first gate. Eventually, the team finally decided to combine the coding part 1 and coding part 2 by removing the “absolute position” command, replace it by using a “motorspeed” command at certain time,adding the brake command and the back thrust part. It is to ensure the AEV have a consistent run in order to complete the MCR.

*Phase*	*Code*
1	reverse(4); motorspeed(4,30); goFor(3) brake(4); goFor(12);
2	reverse(4); motorspeed(4,30); goFor(3) brake(4); goFor(12);
Total Energy	69.56 Joules

From the above system analysis and performance test, the team can concluded that pull configuration provide the best efficiency for the AEV to move around the track. The team decided to use the push configuration from the start point which is the drop-off area to the cargo area. During this time, the AEV is lighter because it does not have any cargo or load, so it does not really required higher efficiency to navigate to the cargo area. On the other hand, the team decided to use the pull configuration from the cargo area back to the drop-off area. Because of the AEV have a load to carry over back to the drop-off area, the AEV will need higher and constant efficiency of the propeller. However, at the end of performance test 3, the team still have a trouble on the sensor. It is because when the team used “absolute position” command, the AEV have many inconsistent runs. When the team increase the mark of the position, the AEV will stop much shorter before the gate. When the team decrease the mark, the AEV will hit the gate. Thus, the team finally decided to combine the first and second code in the Performance Test 2 in order to solve the inconsistent of the sensor and also to have lower energy consumption. Therefore, the final AEV design and final code of the team is from the result of doing the system analysis and performance test

Figure 6: Final Design

–

Figure 7: Supplied Power(Watts) vs Time(seconds)

In figure 6 and 7 above show the team final design and final testing of supplied power against time graph The phases is classified into four phases based on the arduino command. In the table 3 below shows the breakdown of supplied energy of four phases of the AEV for the final code based on the MCR.

Table 3 show the breakdown distances of supplied energy of the final code

Phases	Scenario		Final Code
1	Start at the drop area and stop at the first gate	-Speed at 35 for 4.5 sec -Glide for 2.75 sec -decelerate at 30 for 2 sec -Wait times for 8 sec	reverse(4); motorSpeed(4,35); goFor(4.5); brake(4); goFor(2.75); reverse(4); celerate(4,30,0,2); brake(4); gofor(8);
2	Navigate to the cargo area and stop to pick up R2-D2	-Speed at 35 for 4.3 sec -Glide for 2.75 sec -Wait times for 8 sec	reverse(4); motorSpeed(4,35); goFor(4.3); brake(4); goFor(2.75); reverse(4); brake(4); goFor(6);
3	Travel back and stop at the previous gate	-Speed at 42 for 5 sec -Glide for 2.7 sec -decelerate at 40 for 3.5 sec -Wait times for 8 sec	motorSpeed(4,42); goFor(5); brake(4); goFor(2.7); reverse(4); celerate(4,40,0,3.5); brake(4); goFor(8);
4	Navigate to the drop-off area	-Speed at 42 for 5 sec -Glide for 2.7 sec -decelerate at 40 for 3.5 sec	reverse(4); motorSpeed(4,42); goFor(5); brake(4); goFor(2.7); reverse(4); celerate(4,40,0,3.5); brake(4);

On the day of the final testing, the team has made several runs to make sure every scenario is completed before doing the final testing. After successfully doing the run, the team decided to do the final test. The AEV movement is very stable and did not swaying in any direction. However the AEV had faced problem in stopping before the gate. In its early run before the first gate, the AEV did not reached the first sensor. So, one of the team members had to bring it to the sensor which results in deducted points in the run. It also happens when the AEV was travelling back to the starting point as it did not stops perfectly between the sensors. However the AEV movement was very stable. It also hits the R2-D2 in a very slow motion before bringing it back to the starting point. The total energy consumed during the run was 231 J. It was quite low compared to the other team. The coding and the mass of the AEV are the factors that leads to low energy consumption. The AEV then being assessed by checking its mass and also calculating the other important aspects such as the time of the run and energy per mass ratio. The final score obtained was 61.80 out of 100.

Conclusion and Recommendations

For the past roughly fifteen weeks of classes, the group has spent their time learning about and developing a motorized vehicle that needed to perform a certain task, with the task being to complete the MCR. During the first eight weeks or so, the team spent a majority of their time learning about the important aspects of the AEV project. This included learning about the design process, parts of the AEV, and potential add-ons necessary to the group’s design. The team then used these skills to come up with several designs of an AEV and practiced coding by sending the designs on rough runs across the monorail. The team then chose a couple designs, and a couple types of coding that were their favorites. In the performance tests, the group tested two designs against one another while using the same code as well as testing the two coding styles against one another while using the same design. From the performance test results, the group developed a favorite AEV design and coding style. Finally, the team did whatever was necessary to make their design run along the track as efficiently as possible while still completing the Mission Concept Review. For the last three weeks of class, the group designated all of their time to this.

As shown above, from the performance tests and on, the group dealt with a VERTICAL design and a HORIZONTAL design for the AEV. In the concept scoring sheets, it can be seen that both designs were very similar, but the HORIZONTAL design performed better in the Environmental category, and the team decided that it was best to go with the most efficient design. It can also be seen that the team was working with two styles of coding: a code where the AEV brakes, and a code where the AEV utilizes its momentum to coast along the rail. In graphs that show the energy usage of the types of coding, it is obvious to see that the coding style that utilizes momentum is best for the MCR and efficiency. The group chose their code accordingly. Based on the data of the team’s final testing, the AEV and code used performed very well in the efficiency category. The HORIZONTAL design and coasting code had a Mass-Energy ratio of nearly 1, and this design completed the MCR quicker than roughly 90 percent of the rest of the class. However, during the final runs, the team lost a few points due to inconsistency. Overall, the AEV performed very well for the issues the team had run into.

During the final testing of the AEV, the group dealt with inconsistency issues. This had been problem for the team all semester. When first dealing with coding the AEV, the group had tried to utilize the external sensors to reduce error. However, the AEV would still experience inconsistency issues. The team tested different charged batteries, changed the reflector tape on the wheel, and even tried fiddling around with the sensor wires themselves, but to no avail. The group then decided that the issue must have been within the sensors themselves. Finally, the team moved on to a different coding style that utilized only time and had no reliance on the sensors whatsoever. Since the change, the group had much better luck with consistency than in the past. However, because the team spent so much time on trying to figure out the external sensors, there was not enough time to create a perfect code for the final run, and the group lost some minor points because of it.

The team did a very good job of completing all that was necessary in the AEV project. However, unfortunately, the final runs of the AEV were not perfect. While there were a couple times the run had gone smoothly and without assistance, the team’s AEV was not consistent enough to be considered a working vehicle. The group’s reasoning for this lies within the way they dealt with the errors they had. The team spent too much time on one process, that they didn’t have enough time on the other process when the team finally decided to make the switch. From this, the group learned that sometimes it is better to scrap an idea and try something new rather than spend so much time on repairs. Even with this incomplete consistency, the team is very happy with the performance of their vehicle.

In terms of recommendations the team has for the AEV project, the only thing is to make sure that the external sensors are working properly with the reflector tape. The team still doesn’t necessarily know if the sensors were the issue, but through their problem solving that seemed to be the case. If the sensors were working properly and the issue was human error, then the team suggests that the class spend more time learning about the sensors and less learning about things like the wind tunnel. Otherwise, the structure of the AEV project is very detailed and helpful to the groups in the class.

Final Code

Final Design

Final Energy Graph

The team scoresheet

Brief Report

From the system analysis and performance test, the team can concluded that pull configuration provide the best efficiency for the AEV to move around the track. The team decided to use the push configuration from the start point which is the drop-off area to the cargo area. During this time, the AEV is lighter because it does not have any cargo or load, so it does not really required higher efficiency to navigate to the cargo area. On the other hand, the team decided to use the pull configuration from the cargo area back to the drop-off area. Because of the AEV have a load to carry over back to the drop-off area, the AEV will need higher and constant efficiency of the propeller. However, at the end of performance test 3, the team still have a trouble on the sensor. It is because when the team used “absolute position” command, the AEV have many inconsistent runs. When the team increase the mark of the position, the AEV will stop much shorter before the gate. When the team decrease the mark, the AEV will hit the gate. Thus, the team finally decided to combine the first and second code in the Performance Test 2 in order to solve the inconsistency of the sensor and also to have lower energy consumption. Therefore, the final AEV design and final code of the team is from the result of doing the system analysis and performance test.

Observation for Final Run