Team 192 – Prototyping and Testing for Robot Refinement
· Test 1: The Light Sensor
To deal with the issue of light sensor shielding, we decided to revert to one of our usual methods: surrounding the sensor with black tape, only allowing a small area through which light could reach the sensor. However, we needed to verify whether this would be an effective technique, whether the light would reach the sensor, or whether the sensor itself was working. To test the sensor’s effectiveness, we programmed simple code which would make our Create robot beep and display a message when it saw the light sensor. We then placed the robot on the board, in front of the light, and flipped the light on. Initially, the robot did not beep. We looked at our sensor attachment and saw that we had accidentally covered the sensor. After reapplying the tape, we performed another test. The robot recognized the light immediately. We performed three more tests for accuracy, each yielding the same result. We know now that our shielding technique was effective, and that our robot reacted to the light sensor, which will make starting during the competition easy and eliminate the fear that the robot will not start.
· Test 2: The 90-Second Cutoff
We have never had an issue with our robots running after the 90-second time limit. However, the programming language this year changed from IC to C. While we have had no trouble adapting to the new language, we wanted to make sure that we would have a problem with the cutoff this year, just in case the change to C affected anything. To test the robot’s ability to stop, our programmer downloaded a simple program onto the CBC robot which instructed the robot to drive around in circles, then beep and stop when 89 seconds had passed, allowing for a one second margin of error. We tested the robot on an open table surface, which was closer to the actual surface of the board than our carpeting. We then turned it on and let it run, timing it with a stopwatch. At precisely 89 seconds, the robot stopped and beeped. A repeat of this experiment yielded the same results. We tested the program on the Create as well, with identical success. From this test, we learned that we would be able to stop the robot before it violated the time limit. We then began the more complicated coding, assured that we would not be disqualified for having our robots run over 90 seconds.
· Test 3: The Sweeping Arm
Our Create robot has a Sweeping Arm, which we use to sweep Botguy, Botguy’s foundations, and the fuel containers filled with fuel to the top of the peak. To test the function and accuracy of this attachment and the effectiveness of the code, we ran a few tests on the game board. Initially, we tested the Create without positioning the fuel containers on the board, to see if it could accomplish the simple objective of moving Botguy and the green foundations to the peak. After a few runs, we decided to add the fuel containers to the board. Data from our tests is shown below:
Trial | Points Scored | Notes |
1 | 0 | Create made too wide of a turn, and arm caught on the PVC. Robot reprogrammed. |
2 | 0 | Turn still too wide! Robot reprogrammed. |
3 | 6 | Managed to take both green foundations to the peak, but Botguy fell to the side and was not swept. |
4 | 18 | Got both green foundations and Botguy as well, for a 3X multiplier. |
5 | 9 | Dropped one coupler, but that was because of a positioning error at setup. Now we are ready to begin testing with fuel containers on the board. |
6 | 0 | Robot tripped up by fuel containers. |
7 | 18 | Got the fuel containers and Botguy again but no luck with the fuel containers. Slight programming modifications. |
8 | 63 | Transported green foundations, Botguy, and one fuel container with five green objects inside to the peak. Best run yet! |
Average | 15.375 | Good start! Further refinement is needed, but at least it scores points. |
From these tests, we learned that we need to refine our code, but that the Sweeper Arm itself is an effective attachment and requires little modification. Our observations from these runs were highly instrumental in the further adjustment of our code.