Lesson5.md

@@ -43,7 +43,7 @@ We started by running Bagnall's program [2] without modifications, on the floor
 
 *Video 1: Robot racing around and resting on its light sensor.* 
 
-Going backward on its back is expected behavior, as the sensor in this situation measures a high raw value of reflected light and therefore assumes that the sensor is far away from the ground and tries to flip itself up by setting full speed backwards on its motors. This doesn't work as the robot doesn't have enought power.  
+Going backward on its back is expected behavior, as the sensor in this situation measures a high raw value of reflected light and therefore assumes that the sensor is far away from the ground and tries to flip itself up by setting full speed backwards on its motors. This doesn't work as the robot doesn't have enough power.  
 
 Going backwards on its front is however not expected behavior, as the robot should in fact try to catch its weight by driving forward as it does until the sensor hits the ground. When leaning on the floor the sensor must therefore see a high raw value which means that it doesn't see any reflected light and thinks that it is in fact leaning backwards instead of forward and thereby trying to go backwards. 
 
@@ -55,8 +55,8 @@ With the goal of obtaining a better understanding of the significance of the phy
 3. The robot must be perfectly balanced when the run button is pressed, as the light level measured at that time determines the equilibrium position.
  
 ##### Testing condition 1: A dark room without windows
-We tested the robot in the bathroom where the light could be switced off.
-At first we placed the robot in the middle of the room, started the non-modified program, calibrated it with support from our hands. This attemp made the robot fall over - and thereby not balancing - almost immediately as seen in video 2. 
+We tested the robot in the bathroom where the light could be switched off.
+At first we placed the robot in the middle of the room, started the non-modified program, calibrated it with support from our hands. This attempt made the robot fall over - and thereby not balancing - almost immediately as seen in video 2. 
 
 [![Robot in dark room](http://img.youtube.com/vi/JAj4VaBqbhc/0.jpg)](https://www.youtube.com/watch?v=JAj4VaBqbhc)
 
@@ -107,7 +107,7 @@ After all of these various experiments with change of different factors, we came
 
 
 #### Algorithm-discussion
-Based on Hurbain [2], we know that the PID constants used in ***Sejway.java*** were designed for Hurbain's specific light sensor and environment setup. We therefore decided to start testing which specific variables would be best for our setup. 
+Based on Hurbain [2], we know that the PID constants used in ***Sejway.java*** were designed for Hurbain's specific light sensor, robot build and environment setup. We therefore decided to start testing which specific variables would be best for our setup. 
 
 We thought about (and actually started) changing the PID variables of Bagnall's initial program from integers to floats, but couldn't get it to work and moved on with the initial integer variables to save time. 
 
@@ -158,7 +158,7 @@ To find the best possible setpoint we decided to use the PID values of Bagnall's
 We decided to test the effect of different values for the parameters using a technique inspired by grid search: We selected a range of values to try out for each parameter (*setpoint*, *P*, *I*, and *D*) and then varied one parameter while keeping the others fixed. We began by testing different values with rather large intervals in between, including extreme values (values far away) on either side of the value provided in the code used as inspiration. According to which values gave the best results we then made the search around these values more fine-grained.
  
 *Setpoint:*  
-Noting that the value measured by the robot initially was around 580, we started with a value of 500 to see the effect. We then tried a value of 750 (simply to try something somewhat in the middle between 500 and the highest possible value of 1023). Seeing how poorly both of these affected the robot's performance, we tried a value of 600 which made the robot perform a lot better. After this, we started narrowing in between 600 and 550, ending at a value of 577. After a while of testing, we noticed that the robot was casting a shade depending on the direction that the light was coming from. This has most likely affected the light readings, but we have not taken this further into account except for the awareness that the accuracy of our measurements need to be taken with a grain of salt. Repeated experiments could alleviate the problem.
+Noting that the value measured by the robot initially was around 580, we started with a value of 500 to see the effect. We then tried a value of 750 (simply to try something somewhat in the middle between 500 and the highest possible value of 1023). Seeing how poorly both of these affected the robot's performance, we tried a value of 600 which made the robot perform a lot better. After this, we started narrowing in between 600 and 550, ending at a value of 577. After a while of testing, we noticed that the robot was casting a shade depending on the direction that the light was coming from. This has most likely affected the light readings, but we have not taken this further into account except for the awareness that the accuracy of our measurements need to be taken with a grain of salt. Additionally, the values we arrived at were specific for the exact ambient lighting in the room we were in at the time. Any change in lighting would change the ideal setpoint, and we'd have to do these readings again.
  
 *P value:*  
 In the code that we used as basis for our own, ***p*** was 28.
@@ -170,6 +170,7 @@ Additional observation: The robot seems to stop briefly once in a while. This se
 NOTE (Camilla): Måske skal vi have en video for ovenstående additional observation?
 
 *I value:*
+
 We observed that once the robot started falling in any direction (forwards or backwards) it would generally keep slowly falling in that direction until tipping over (despite also driving in that direction in an attempt to balance). As such, we needed a stronger reaction on past accumulated errors, which is exactly what the integral variable controls, so we experimented with different I-values.
 
 Initially the I-value was 4, and as just explained we needed a stronger reaction on past errors, so we attempted increasing it.