Lesson5.md

@@ -109,7 +109,7 @@ In order to optimize our experimentation with various PID values for the program
 #### Making the programs
 To make a GUI that runs on a computer and communicates variable values with the program running on the NTX we retrieved the ***TrackerController.java*** and the ***Tracker.java*** from [lesson 2](TODO ref) which was used respectively for controlling the PID values used on the NTX and receiving and using these values in a PID controller for the ultrasonic sensor. The ***TrackerController.java*** hence became the inspiration for our PC GUI and the ***Tracker.java*** for the NXT program responsible for receiving the sent values. 
 
-Later on we noticed that the lesson plan actually gave two java programs to use as inspiration, but at this point we had already written the program ourself and therefore ignored them. 
+Later on we noticed that two java programs to use as inspiration were actually provided in the lesson plan, but at this point we had already written the program ourselves and therefore chose to ignore the supplied programs as we would rather continue with our experiments. 
 
 We ended up writing (basically through capy-paste though) four programs; ***PICcontroller.java***,  ***PCconnection.java***, ***Sejway.java*** and ***NXTSegwayRunner.java***. 
 
@@ -252,7 +252,7 @@ Afterwards, we modified the Gyrotest to let both motors run while the program wa
 There seems to be no significant difference between having the engines running and having them turned off - there is only a difference of 0.1 between the average readings in the two cases. We concluded that the average drift was negligible in both cases. 
 It is interesting that the average reading this time (in both cases) was closer to 597 than to 598, as opposed to what we concluded from the preceding run. However, this is only a marginal change and if time permitted we shoul probably run several long tests to obtain an overall average and use that. 
 
-Based on the code in [Ref or lesson plan], we tried implementing integration to calculate the angle of the gyro based on the sample interval and the gyro motion readings. The result was however extremely inaccurate, and would for some reason slowly slide in one direction, even when the gyro was motionless. We assumed this was a result of the constant small speed readings made by the gyro even when still, but these should work in both directions as the offset remains the same despite fluctuations to either side, so the drifting angle is a mystery.
+Based on  code presented in [Ref for lesson plan], we tried implementing integration to calculate the angle of the gyro based on the sample interval and the motion readings of the gyro. The result was, however, extremely inaccurate, and would for some reason slowly slide in one direction, even when the gyro was motionless. We assumed this to be a result of the constant small speed readings made by the gyro even when still, but these should work in both directions as the offset remains the same despite fluctuations to either side, so the drifting angle is a mystery to us. 
 
 We would have attempted to amend the inaccurate angle calculation and then use this as a means of creating a balancing robot using the gyro sensor, but at this point we had simply spent too much time on the exercises and were forced to cut our gyro implementation short and leave it at this. Had we had the time to continue, our ideas regarding the implementation of a balancing robot included combining the different sensors to have a form of "second opinion" to take into account when responding to the gyro sensor's readings.