... | @@ -195,7 +195,7 @@ After experimenting for a long time with the P, I and D variables based on past |
... | @@ -195,7 +195,7 @@ After experimenting for a long time with the P, I and D variables based on past |
|
|
|
|
|
However, a new problem arose. The robot would go crazy when hitting the intersection at the Y-sections, due to the sudden unexpected values read by both sensors, since there are two black lines going in separate directions. The results were a completely unpredictable robot flying in every and all directions when hitting the intersection due to it’s powerful attempts at correcting the sudden big error values being read.
|
|
However, a new problem arose. The robot would go crazy when hitting the intersection at the Y-sections, due to the sudden unexpected values read by both sensors, since there are two black lines going in separate directions. The results were a completely unpredictable robot flying in every and all directions when hitting the intersection due to it’s powerful attempts at correcting the sudden big error values being read.
|
|
|
|
|
|
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.
|
|
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) as seen in Code Snippet 1, and then continue its line following up the ramp.
|
|
|
|
|
|
```java
|
|
```java
|
|
Car.forward(70, 70); //Drive past the Y-section
|
|
Car.forward(70, 70); //Drive past the Y-section
|
... | @@ -206,7 +206,7 @@ To solve this problem, we decided to use it to our advantage. The wild behavior |
... | @@ -206,7 +206,7 @@ To solve this problem, we decided to use it to our advantage. The wild behavior |
|
Car.forward(70, -70);
|
|
Car.forward(70, -70);
|
|
}
|
|
}
|
|
```
|
|
```
|
|
*Code snippet 1: TODO description --huuuusk ref til **_PIDGod.java_** linje 127-133*
|
|
*Code snippet 1: Line 127-133 of the **_PIDGod.java_** program, that gets the robot past the Y intersection by driving forward for 300 miliseconds and then keeps spinning until it finds the black line to follow up the ramp*
|
|
|
|
|
|
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.
|
|
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.
|
|
|
|
|
... | | ... | |