Final Design, Code, & Performance

Our Final Design:

Final Design

Our Final Design Performance Analysis:

       Figure 1: Power (Watts) vs. Time (Seconds) for the Final Performance Test

During the performance test, our groups biggest takeaways from what was completed were that time-control method is more controllable for the distance compared to the distance-control method. Also, we needed to design some code, even if it consumed more energy for the qualified repeatability and controllability. The reproductivity and consistency were two crucial factors that determined the final result of tests. We failed on the official Performance Test 1 because of consistency problems, which made us consider how to improve the code in Performance Test 2.

We also found that we should change the arguments of the motorSpeed() method when we wanted to make a big change for the distance because it would affect the accuracy of the result greatly as the time-cumulative effect would cause the total change in distance to be unpredictably bigger than expected, as the following the parameter of  goFor method (after moterSpeed method) was usually a relatively big time-interval. However, we found it was better to change the arguments of goFor() method when we wanted to make small change in the distance traveled because the total distance would change drastically if we changed the arguments of motorSpeed() – the accumulation effect would have been great as even a small change (+1 or -1) on the code could cause this.

                  Figure 2: Power (Watts) vs. Distance (Meters)

Figure 2 shows the difference of the two code patterns. It can be easily observed that the behavior of the most part of the two runs was almost identical, which not only shows the code patterns owed by both had a steady controllability and repeatability over AEV, even after the AEV picked the caboose, but also verified choosing the braking method and time-control method were more applicable ways to control the AEV. For the different part of the figure, the red curve used less motor power to brake the AEV compared with the blue curve. Although the red curve consumed less energy, this is not the best result for the final performance test – we need to recross the gate. The red curve made the AEV run out of the sensored distance of the gate, while the the blue curve could stop at the position that lies in the sensored distance of the gate. We realized that not only more motor power was needed to generate the forward force but also need enough time to let the AEV pass the uphill, which is why we used the bigger parameter for moterSpeed() method in coding design.

The AEV completed it’s Final Performance Test in 55 seconds using 232 J of energy.

Our Final Performance Code:
//reflectanceSensorTest();
// Setup motors, go to the gate
motorSpeed(4,42);
goFor(3.9);

//Reverse the motors for braking to contole the sliding distance
reverse(4);
motorSpeed(4,55);
goFor(1);
reverse(4);

// Stop motors, wait for 7 seconds
motorSpeed(4,0);
goFor(8);

//Run the AEV
motorSpeed(4,33);
goFor(4);
brake(4);

//Brakeing for stopping the AEV
reverse(4);
motorSpeed(4,33);
goFor(0.9);
brake(4);

//Stop 5 seconds
motorSpeed(4,0);
goFor(9);

//Keep going
motorSpeed(4,60);
goFor(2.5);
reverse(4);
motorSpeed(4,63);
goFor(2);
brake(4);
reverse(4);

// Stop motors, wait for 7 seconds
motorSpeed(4,0);
goFor(12);

//Run the AEV
motorSpeed(4,42);
goFor(2.8);
brake(4);

//Brakeing for stopping the AEV
reverse(4);
motorSpeed(4,74);
goFor(2.1);
brake(4);