@@ -203,8 +203,6 @@ However, a new problem arose. The robot would go crazy when hitting the intersec
To solve this problem, we decided to use it to our advantage. The wild behavior exhibited by the robot clearly indicated the sensors reading values they otherwise never would. In this case, since the robot followed the line very reliably centered, it would always enter the Y-section in a way that both sensors were reading black (or very close to black). We simply did a check for both sensors reading black, and when this happened, we wanted to turn. Now that we could check for a turn on the exact Y intersection, finding the next line became much easier. We just had the robot drive forward a very short distance, and then rotate right until the right sensor read black (it hit the black line going up the next ramp), and then continue its line following up the ramp.
@@ -214,7 +212,7 @@ To solve this problem, we decided to use it to our advantage. The wild behavior
*Code snippet 1: TODO description*
*Code snippet 1: TODO description --huuuusk ref til **_PIDGod.java_** linje 127-133*
The same method was used for the second platform’s turn, although we had to adjust the values for what was acceptable to be considered ‘black’ on both sensor for it to trigger the turn, as the intersection was slightly differently skewed on the second ramp, causing a different pattern of sensor values compared to the first platform. This implementation worked extremely well, and the robot would now very reliably drive all the way to the top of the track, while now also cutting off some time by not having to drive all the way to the back of the platforms. As for turning around the robot on the top platform, we switched to using the Tacho counter to reliably turn exactly 180 degrees. We experimented in a separate program for a while to figure out which values equated to a 180 degree turn, and ended up with a tacho value of 385 working well.