Lab 9 – Performance Test 2

Arduino Code

 

In performance test 2 of lab 9, the team created two different codes that met the requirements outlined in the Mission Concept Review (MCR). The MCR simply laid out a scenario that the AEV must complete on the overhead track. Essentially, the AEV would start at the drop-off area, travel to the gate, traverse through the gate, travel to the cargo, pick up the cargo, travel back through the gate to the drop off area, and stop. Both code solutions created by the team should successfully complete this scenario. However, by creating two different codes, the team can choose certain criteria that they value most to focus on and analyze. This criteria may include energy efficiency, difference between similar command calls, flexibility to various tracks, and so on. Performance test 2 allowed for the team to choose the best of two codes to use in performance test 4, the final testing of the AEV on the overhead track.

 

A breakdown of the first code is shown below:

 

 

The team decided that beyond completing the basic scenario in both codes, they wanted to target the AEV’s propellers to find the most optimal energy efficiency. Therefore, the team focused both codes on motor control which further controls the propellers. In the first code, the team ran both propellers at the same time for the entirety of the code besides when the AEV was braked. On the way to the cargo, the propellers were in the pusher position. On the way back to the drop-off area with the cargo attached, the propellers were in the puller position. The team chose to run the propellers with these configurations specifically because when the AEV is attached to the cargo, it is heavier and to pull it the motorSpeed() would have to be increased. This would require the Arduino to use more energy. By using the puller configuration whilst the weight is increased, the energy efficiency can be optimized. The second code ran only a single propeller at a time going to and from the drop-off area. The propeller would be in the puller configuration at all times. Both codes were developed in a very similar way. They both used the goToAbsolutePosition() command call and attempted to pinpoint the exact marks where the AEV would need to stop. When the team arrived to PT2 with their two developed codes, they realized their solution was not feasible. The first time they ran their first code on the track, it ran into the gate.

 

The team developed a new code in which they would turn off the brakes of their AEV 50 marks before the actual stopping mark to allow for the AEV to slowly coast to a complete stop. This solution was more feasible than the first, yet the team still faced obstacles. The team engaged in a repetitive cycle of attempting to find the ‘perfect’ mark to slow the AEV down at, but they anytime they would test their ‘perfect’ solution, it would fail after testing it more than 2 times. The team, frustrated with the code’s inconsistency, decided to attempt to find a new solution.

 

A code breakdown of the second code is shown below:

 

 

As time in Performance Test 2 was limited, the team finished perfecting their code in Performance Test 3.

 

Important takeaways were drawn from Performance Test 2, including that:

  1.  The team 2 different codes created met most of the MCR requirements, but still need to be perfected.
  2. The team identified the importance of positioning the sensors correctly in regards to the command call goToAbsolutePosition().
  3. The team recognized that the wheel reflective tape was old and preventing the sensors from working correctly.
  4. The team recognized the importance of time management as they did not complete all of their goals set for performance test 2.

 

Full PT2 Progress Report