Memo
Date:
To:
From:
Subject:
November 15, 2015
Inst. John Schrock & GTA Jin Yang
Sally Zhou, Nikhila Cooduvalli, Wei Zhi Tan, Ryan Stutzman
Lab 09- Performance Test 2
Introduction
The efficiency of the code was tested during Performance Test 2. The group programmed the arduino
based on criterias given for the scenario. In the scenario, the AEV travels from starting point to the gate.
When the sensor activates and open the gate after seven seconds, the AEV proceeds forward to pick up
the cargo. At the pick-up location, the AEV will wait five seconds before traveling back to the gate and
back to the starting point. The program must be complete in under 2.5 minutes. In order to increase
efficiency of code, multiple codes were to be generated to compare the energy usage. The strategy used
to improve energy efficiency and results of the test will be discussed along with data collected from the
AEV.
Results & Discussion
The data collected during the lab is shown below. Figure 1 represents the amount of Power vs. Distance
traveled by the AEV during the lab. Figure 2 represents the different phases of energy the AEV used
while traversing the track. During the experiment, the total energy used was 225 Joules.
Figure 1, the power vs. distance graph shown below, represents the amount of energy that was used
throughout the mission. The graph looks highly repetitive and can be split into four different sections
due to the four phases of the mission. The first section and second section of the graph are very similar
because the code to get from the start to the first gate and from the gate to the caboose is almost the
same. Similarly, the third and fourth sections of the code are very similar so the graph is also identical.
The plateau from .5m to 3m indicates a constant amount of energy was used and this can be seen from
the goToAbsolutePosition() command that was used in Figure 2 line 12. The remaining plateaus in the
graph can also be attributed to a similar goToAbsolutePosition() command. Every time a brake
command was used, the power used decreased and the graph returned to zero, which can be seen at a
distance of 3m.
Figure 1: Power vs. Distance graph of Group J’s AEV
Figure 2: Phase breakdown of AEV run
Figure 2, above, represents the phase breakdown of the AEV’s run. It can be observed that phases 2, 6,
10, and 13 are all very similar and use a constant amount of energy. These correspond to the
goToAbsolutePosition() and goToRelativePosition() commands. Similarly phases 1, 5, 9, and 13 all
correspond to the same piece of code. The phase breakdown graph also shows how repetitive the code
was to complete the mission. Table 1, in the appendix represents the amount of energy that was used
over each position and time. By looking at the table it can be seen that Group J’s AEV used 250 Joules of
total energy.
Figure 3, in the appendix, represents the code that was used to complete the Mission given in the MCR.
The code was broken up into four separate sections. The first section corresponds to the AEV traveling
from the start to the gate. The second section is the AEV moving from the gate to the end of the track
and picking up the caboose. The next section corresponds to the AEV traveling back to the gate with the
caboose and the final section is the AEV stopping at the end. In each part of the code, similar commands
are used. The most important commands are goToAbsolutePosition() and goToRelativePosition(), figure
2 lines 7 and 10, because those indicate how far the AEV must move before changing speeds or
directions.
Based on previous labs, Group J learned the most efficient commands are celerate() and goFor() and the
most inefficient commands are reverse(), brake(), and motorSpeed(). The reason celerate() uses less
energy is because its parameters require the programmer to enter an initial speed, ending speed, and
time. Since it asks for a time, the program slowly builds up speed so less energy is used. When
motorSpeed() is called the power is increased rapidly and this causes a larger amount of energy to be
used. The goFor() command keeps the vehicle moving at a constant energy so there is not much power
input needed while this command is used. The reverse() command causes the vehicle to abruptly change
motion which also causes a large amount of energy. With this knowledge in mind, Group J wrote a code
that completed the mission given in the MCR while attempting to use the least amount of energy
possible.
The programming strategy that the group employed had one main focus; get it to work as described in
the MCR. It needed to start at the designated marks. Then travel to the gate and only trip the first
sensor and not the second. Then it needed to wait 8 seconds for the gate to be opened to allow the AEV
to travel through. It then needed to travel to the cargo area to pick up an R2-D2. Once it had an R2-D2
securely attached it must travel back to the gate to check-in without tripping the second sensor. Once
again it must wait 8 seconds for the gate to be opened. Once the gate opens, it must continue to the
drop-off area to drop off the R2-D2. The second focus was for energy efficiency. The group tried to make
its code as efficient as possible by trying to use the engines as little as possible. This means getting the
AEV started and letting it coast as far as possible. In Figure 1 above, it is easy to see when the engines
are cut off and the AEV is coasting. When the AEV starts moving again, it receives a little boost to get
started. Then once it is moving the engines slow down to a speed that is able to make it just continue to
move. On the final run, the group was able to make the AEV complete the whole mission.
While the group ran into issues and had to tweak certain parts of their code, they kept in mind that
energy efficiency was a top priority. For example, one run of the AEV went too far when it reached the
gate and it tripped the second sensor. When this happened the gate locked and would not open. To
remedy this, the group didn’t increase the braking power or duration because this would increase the
energy that is used. Instead the group decided to cut off the engines earlier. This would allow the AEV to
coast a further distance which saves energy. Since the braking power and duration is the same, the AEV
should come to a stop earlier due to the fact that the AEV would have slowed down drastically more by
itself therefore enabling the brake to stop the AEV sooner.
While Group J was testing the code for Performance Test 2, they might have encountered a couple
issues that could have led to skewed data. For instance, the group was unaware the track in the
classroom upstairs was slightly different than the track in the downstairs classroom. Due to this, the
group made frequent modifications to their code so their vehicle could complete both tracks when in
reality it wasn’t possible for the same code to finish both tracks. During the first run of the code on day 1
the AEV reached the gate while traveling at 35% power. However, during the next run on the same track
with the same code, the AEV appeared to be moving significantly slower which could have been due to
an uncharged battery since no other factors had been manipulated. Another factor that could have
caused an error was that one of Group J’s motors stopped working after the wire broke. This forced the
group to use a new motor which might have performed differently than the initial motor they were
using.
During the first test run of the AEV, the AEV was moving in the opposite direction the team wants it to
move. This is because during this performance test, the team had the AEV starting from the point where
it is supposed to be but of the track while we used to test it from the ending point as it is much closer to
the table of Group J. Such silly mistake was fixed by reversing the body kit that holds the wheels. After
fixing the errors mentioned, another error occurs. The AEV finally able to move but it does not seems to
be able to reach the gate using the code the group used all the time. We soon find out that one of the
propeller is broken, one propeller is never going to produce enough energy to move the whole AEV
using the code we installed. So, we asked for a new engine from a TA to replace the broken one. Group J
once again encountered a same issue during this Lab was that the sensors were not functioning
correctly when they initially placed their AEV on the track, which caused it to always move forward
without looking at the distance it was traveling. To resolve this issue, the group had switched the
polarity of the wires connecting the sensors to the board so it could differentiate between moving
forward and moving backwards. This allows the AEV to determine the distance it was traveling.
Recommendations & Conclusion
There are a couple things the group would recommend to improve the AEV project in the future. One
thing is to provide every team the exact same battery they used every lab and make sure they are fully
charged. During the lab, the group had to continually re-write and make several trial of runs to make an
accurate set of coding. This is because different batteries provide slightly different power. It derails the
process and is usually the main cause of this re-evaluation of coding. By using the same batteries every
test runs, every team will have have more consistent runs every time during the lab and it is able to
prevent accidents for example, the AEV goes too fast and hit the caboose or gate while damaging them
from happening. Besides that, according to the GTA, the tracks in three different lab have different
length. The group also have to re-code according to the track we use on that day. The group suggests
the lab to be carried out at the same lab every time in order to save time and allow the team to
maximize the efficiency of the code they are running.
In conclusion, with the many errors that the group had encountered, the group was only able to
generate one code that completed the mission. Due to varying tracks in lab rooms, the group spent lots
of time modifying the code during each session. Also, usage of inconsistent part, such as the battery and
the motor, the code had to be re-adjusted to meet the mission criterias. With each adjustment,
programmers continued to prioritize energy efficiency. The result of the final test run used 250 Joules of
energy.
Appendix
reverse(4);
//===================================================
//
GO TO GATE
//===================================================
// accelerate all motors from start to 35% power in 2 seconds
celerate(4,0,35,2);
// Run all motors at a constant speed (35% power)
motorSpeed(4,35);
goToAbsolutePosition(50);
motorSpeed(4,15);
// Travel a distance of 13.5 feet
goToAbsolutePosition(280);
brake(4);
goToAbsolutePosition(365);
// Reverse all motors
reverse(4);
// All motors at 25% power
motorSpeed(4,25);
// For 1 sec
goFor(1);
// Brake all motors
brake(4);
//===================================================
//
WAIT FOR GATE TO OPEN
//===================================================
goFor(8);
//===================================================
//
GO TO END TO PICK UP CABOOSE
//===================================================
// Make the motors go forward again
reverse(4);
// accelerate all motors from start to 35% power in 2 seconds
celerate(4,0,35,2);
// Run all motors at a constant speed (35% power)
motorSpeed(4,35);
goToAbsolutePosition(430);
motorSpeed(4,15);
// Travel a distance of 13.5 feet
goToAbsolutePosition(725);
brake(4);
goToAbsolutePosition(790);
// Reverse all motors
reverse(4);
// All motors at 23% power
motorSpeed(4,23);
// For 1 sec
goFor(1);
// Brake all motors
brake(4);
goFor(2);
//===================================================
//
GO BACK TO GATE AFTER CABOOSE PICK UP
//===================================================
// accelerate all motors from start to 50% power in 2 seconds
celerate(4,0,50,2);
// Run all motors at a constant speed (50% power)
motorSpeed(4,50);
goToAbsolutePosition(740);
motorSpeed(4,30);
// Travel a distance of 13.5 feet
goToAbsolutePosition(550);
brake(4);
goToAbsolutePosition(480);
// Reverse all motors
reverse(4);
// All motors at 30% power
motorSpeed(4,30);
// For 1 sec
goFor(1);
// Brake all motors
brake(4);
//===================================================
//
WAIT FOR GATE TO OPEN
//===================================================
goFor(8);
//===================================================
// GO BACK TO START FROM GATE WITH PACKAGE
//===================================================
// Reverse all motors
reverse(4);
// accelerate all motors from start to 50% power in 2 seconds
celerate(4,0,50,2);
goToRelativePosition(-50);
motorSpeed(4,35);
// Travel a distance of 13.5 feet
goToAbsolutePosition(150);
brake(4);
goToAbsolutePosition(90);
// Reverse all motors
reverse(4);
// All motors at 40% power
motorSpeed(4,40);
// For 1 sec
goFor(2);
// Brake all motors
brake(4);
Figure 3: AEV Arduino Code to Complete Mission