Lesson8.md

@@ -205,6 +205,17 @@ To solve this problem, we decided to use it to our advantage. The wild behavior
 
 [TODO: Camilla, Insert code from **_PIDGod.java_**, linje 127-133 - husk ref!!]
 
+```java
+	Car.forward(70, 70); //Drive past the Y-section
+	Thread.sleep(300);
+				
+	//Keep spinning right until seeing black line
+	while(!(rightSensor.light() < (rightSensor.getBlackLightValue() + 5))) {
+		Car.forward(70, -70);
+	}
+```   
+*Code snippet 1: TODO description*
+
 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 turns mostly worked fine on the way down as well, although the robot would not follow the line as reliably down the ramps as it did up. The reduced power needed because of gravity meant the robot would correct too much at times, and we tried to remedy this by changing our PID variables once the top of the track was hit. After much experimentation, we arrived at the variables P = 5, I = 0.5, d = 15. Additionally, we started limiting the motor power by cutting the final power variable down to 80, if it was above 80. This eliminated the situations where the robot would reconfigure its power too strongly, and completely lose control.