For performance test one, the objective is to place an AEV behind the red line marking the starting location then propel the AEV to the first gate sensor. Upon passing the first gate sensor, the AEV should stop before the second gate sensor and wait 7 seconds before proceeding. The AEV should propel itself to the end of the rail and brake coming to a stop around the red line marker. Two designs were tested to see which was better.
Figure 1: Design 1
Figure 2: Design 2
The two prototypes had a very similar Power vs Time graph. The first prototype however has very slightly larger constant power at the beginning while accelerating. The first prototype also has a slightly lower constant power after the braking spike.
Figure 14: Power Vs Time for the Code for two Prototypes
The first performance test was to complete a code that allows the AEV to travel to the gate and trigger the sensors, wait until the gate opens, and travel through. The code commands used were running the motors for a certain amount of time.
This was found to have many problems. First of all, the time commands have a very unreliable consistency, which can mess up the entire run if the first driving command does not get the AEV to where it needs to go. The other problem with time commands is that it is reliant on the battery power. As the tests continued and the battery lost more power in this testing it was observed that the AEV would reach less of a distance for each run and this needed to be adjusted to reach the needed distance.
The numerical values for the graphs are in the results section but there is a definite trend between the two designs. Both prototypes have an almost constant increase in power to achieve the programmed power, then both power’s drop off while it coasts, and finally there is a spike in power while the opposite motor does a quick brake. The difference between the two designs is that the second is slightly worse. The battery placement creates some drag which makes the power and distance slightly smaller than design one. This smaller power made it so the design didn’t make it to the gate and it had to be manually triggered. The evidence that Design one is better is because it was able to complete the task and design two was not.
The source of error from these runs is that the starting position, while the experimenter tried to keep as consistent as possible, will have varied a small amount. With this small variation in starting position it can disrupt an entire run, especially with the unreliability of the timing commands used in the first performance test.
The major trend takeaways from this first performance test is that using absolute and relative positioning is a more accurate way to get the AEV to a position. Using time condition are very inconsistent and depend on the battery power while the distance commands keep the AEV moving until a specifically coded position. The main errors, as previously talked about in the discussion section is the inconsistency of using a timing program. The achievement of completing performance test 1 had a small amount to od with luck that the trail that was graded wasn’t an outlier and did what was intended. To fix this the team will use position commands for all major movements from now on.
This would also be the recommendation to other teams. Not to waste time fine tuning a code with timing for distance in it because it will have to be changed with the battery and even then there is no guarantee it will be accurate. The other part of this test that will have to be changed for the future tests is that the custom propeller did not arrive yet. It is unclear if they will arrive at all but if they arrive at any point the coed will have to be adjusted because they provide more thrust than the two bladed propellers that are implemented now.
Code for Performance Test 1
reverse(2);
celerate(2,0,60,1);
motorSpeed(2,60);
goFor(4.3);
brake(2);
reverse(1);
motorSpeed(1,63);
goFor(1.5);
motorSpeed(4,0);
goFor(7);
motorSpeed(2,60);
goFor(3);
motorSpeed(1,70);
goFor(1.5);