Performance Check 1

Performance Check 1

Date: 3/3/2023

Test Duration: 10:30AM-10:55AM

Number of Runs Performed: 3

Team Members Present: All

What was being tested: The robot’s ability to start upon seeing a light, drive up a ramp, and hit the kiosk.

Run 1: realized that the CdS sensor was too sensitive due to the values in the code, leading to false starts in the run. Aborted the test to alter the code.

Run 2: the back right wheel was experiencing traction issues, so an additional rubber band was added, and practice runs were held.

Run 3: Practice runs were successful, so we had our third test and received all of the points- perfect run plus bonus. Additional notes for the future involve using hot glue to secure the wheels.

 

Video attached is the successful run.

PerformanceCheck1.mov

 

Reflection: 

For performance checkpoint one, the robot had to begin moving once a light below it was turned on and then navigate up the shallow ramp, through the upper deck of the course to touch the kiosk. Our design met these specifications well. The motors powered the back wheels around the course as expected and the code performed reliably. Also, the CdS cell was properly positioned to be able to pick up the light signals.

A few unexpected hardware problems arose: the robot had traction issues, particularly with the right wheel going up the ramp, and occasionally, the wheels fell off the motor axles due to large tolerances in the Du Bro adaptors. The solution to the first problem was to wrap rubber bands around the back wheels to increase the contact area with the ground and prevent the right wheel from spinning out. To solve the second problem, the plan is to secure the wheels to the adaptors using glue. Once rubber bands were wrapped around the wheels, the robot was able to turn after moving up the ramp more consistently.

Considering the team was a little behind schedule (manufacturing parts in the robot shop taking longer than expected), fewer tests were able to be performed before Friday’s checkpoint which may have also led to the above hardware issues not being caught earlier. We also didn’t add the CdS cell to the robot until the night before the performance check, which was less than ideal for testing as well. Now that we have a better idea of the time commitment it takes to make different parts, we will be able to better manage our time to allow for more testing before future checkpoints.

Despite these issues, the design for checkpoint one still had considerable strengths such as the design of the chassis itself, which allowed for wires to reach the proteus without hindering the wheels and the code, which allowed the robot to reach the kiosk without relying on RPS. The secure design of the chassis should be left alone for the future, but the code should be tweaked so that it is able to redirect itself if off course, something hardcoding directions into doesn’t allow. The use of RPS within the code as well as the addition of microswitches (which have been purchased but not assembled quite yet) will allow the robot to move around the course in an accurate and consistent manner.