Lesson5.md

@@ -109,7 +109,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. 
 
-***TODO Camilla: Skriv at vi havde problemer med at få det til at virke med floats og derfor valgte at se bort fra Oles råd om at ændre til floats*** 
+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. 
 
 In order to optimize our experimentation with various PID values for the program, we decided to make a PC GUI program to send new values to the robot over Bluetooth, on-the-fly while testing, rather than having to upload a new program with every value change.
 
@@ -129,10 +129,10 @@ The ***PCconnection.java*** is inspired from the ***Tracker.java*** and therefor
 
 The ***Sejway.java*** program is a modification of Bagnall's Sejway program, where the PID variables are set through setter-methods called by outsiders - in our case the PCconnection instance. This program thereby controls the actual balancing abilities of the robot.
 
-As both these programs can't run simultanously on the NXT, we also made the ***NXTSegwayRunner.java*** program which simply starts a Sejway instance, starts it, starts a PCconnection instance with a reference to the Sejway instance. This also means that the upper two classes extends Thread to enable simultaneous execution. 
+As both these programs can't run simultanously on the NXT, we also made the ***NXTSegwayRunner.java*** program which simply creates a Sejway instance, starts it and creates and starts a PCconnection instance with a reference to the Sejway instance. This also means that the upper two classes extends Thread to enable simultaneous execution. 
 
 #### Search for good PID parameters
-After implementing the programs enabling easy PID parameter search, we started playing around with different values for P, I and D by using a by-hand-calibrated setpoint. We quickly realized that this method didn't enhance our understanding of the different variables and neither the robot's ability to self-balance. We therefore decided to use a more systematic way of testing and deciding on variable values than this approach based on gut feeling and experience (the latter of which we have very little).  
+After implementing the programs enabling easy PID parameter search, we started playing around with different values for P, I and D by using a by-hand-calibrated setpoint. We quickly realized that this method didn't enhance our understanding of the different variables and neither the robot's ability to self-balance. We therefore decided to use a more systematic way of testing and deciding on variable values than this approach based on gut feeling and experience (the latter of which we had very little).  
 To systematically observe which values of P, I and D work better for our robot we needed to have a best possible starting point (i.e. the robot being in equilibrium), wherefore we set out to find a good setpoint. 
 
 ##### Finding a good setpoint
@@ -150,20 +150,15 @@ To find the best possible setpoint we decided to use the PID values of Bagnall's
 | 578            | OK       | Pretty good initial balance with no preferred fall-direction|
 | 577            | OK       | Maybe better - really hard to tell |
 
-*Table 1: Observations for the effect of various setpoint values for the balancing robot*
+*Table 1: Observations for the effect of various setpoint values for the balancing robot as moving towards better values*
 
 
 ##### Grid-inspired search and extrema exploration
 
-(Camilla og Nicolai nåede hertil - for nu)
-NOTE: Planen for resten af dette afsnit er: 
-4. Resultater fra GRID search
-5. konklusioner
-
 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 then 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 th 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. Repeated experiments could alleviate the problem.
  
 *P value:*  
 In the code that we used as basis for our own, ***p*** was 28.
@@ -172,8 +167,9 @@ Using the grid search approach again, we first tried with 40 (robot falling forw
 We changed the setpoint to 585 and tried values of p between 40 and 70. As before, 70 caused violent oscillations and instability. Both 55 and 40 seemed more stable. We decided to continue testing with a value of 40. 
 Additional observation: The robot seems to stop briefly once in a while. This seemed to happen more with p = 70 than with p = 40. 
 
-*I value:*
+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.
@@ -193,7 +189,9 @@ We decided to finish up the experiments (long) before having tried all possible
 ### Self balancing robot with color sensor
 ---
 We replaced the light sensor with a color sensor and did some trial runs with the robot to see how well it performed on the basic settings (p = 28, i = 4, d = 33). These initial runs led to the following interesting observation: 
-Changes in the robot's position seemed to be reflected less strongly in the readings of the color sensor than those of the light sensor - that is, the same angle seemed to induce less of a change in the color sensor's readings. We therefore speculated that we needed to multiply the error by a larger value in order to adequately correct the robot's position, which means that a larger value of *p* might result in the robot balancing better as the change in reading would then have a larger effect. We tested this by trying out different values of ***p***, using the same *p*-values as when testing the light sensor. We weren't able to observe any improvement for certain and did not press on with this approach. Instead, we decided to compare the two types of sensor more closely.
+NOTE (Camilla): Havde vi ikke ændret til værdierne fra forrige eksperiment? Altså p = 40, i=6 ?)
+
+Changes in the robot's position seemed to be reflected less strongly in the readings of the color sensor than those of the light sensor - that is, the same angle seemed to induce less of a change in the color sensor's readings. We therefore speculated that we needed to multiply the error by a larger value in order to adequately correct the robot's position, which means that a larger value of *p* might result in the robot balancing better as the change in reading would then have a larger effect. We tested this by trying out different values of ***p***, using the same *p*-values as when testing the light sensor. We weren't able to observe any improvements for certain and did not press on with this approach. Instead, we decided to compare the two types of sensor more closely.
 
 
 #### Comparison with light sensor
@@ -225,13 +223,16 @@ Further exploration might have included testing the color sensor in different co
 
 ### Self balancing robot with gyro sensor
 ---
-(TODO alle: INTRO)
+After having tried both light and color sensors to get the robot standing we moved on to a gyro sensor. This sensor gives readings of movement and would therefore be ideal for a two wheel balancing robot. These motion readings are ment to be 600 (in raw values) [TODO ref] when completely steady and return smaller or greater numbers depending on the direction of the motion. How much smaller or greater these values are depends on the speed of the motion, as the returned gyro value is measured in angle velocity.
+However not all gyro sensors have a stand still value of 600. It might be either greater or lower depending on the specific gyro [TODO ref]. Therefore we started by measuring our specific gyro sensors steady value - called offset. 
+
+This was done by placing the robot against a wall, and observing the value over a period of time. The reading varying between 597 and 598, with 598 occuring the most. Our sensor's offset for angular velosity is therefore 598 and not 600 as [TODO ref article writer name] suggests.
 
-The offset was measured by placing the robot against a wall, and observing the value over a period of time. The reading varying between 597 and 598, with 598 occuring the most. Our sensor's offset for angular velosity is therefore 598.
+Gyro sensors does not only vary in offset value, they also vary in measured value depending on surronding temperature and given voltage [TODO ref]. This is called the drift of the gyro, as the initial offset value will move when these factors effect the sensor.
 
-To test the drift, we began by starting ***GyroTest.java*** and letting it run for 10 minutes to check if the sensor developed heat which could then maybe result in a drift of the reading value. This didn't seem to be the case - in the end, the sensor readings were still shifting between 597 and 598. 
+To test the drift of our sensor, we began by starting ***GyroTest.java*** and letting it run for 10 minutes to check if the sensor developed heat which could then maybe result in a drift of the reading value. This didn't seem to be the case - in the end, the sensor readings were still shifting between 597 and 598. 
 
-Afterwards, we modified ***GyroTest*** to let both motors run while the program was running, in order to see the effect of the resulting voltage drop. We also added a data logger to the program to gather information for later observations. We used this to calculate the average reading and the average drift, presented in table 2 below. Two cases were investigated: In the first case, the robot was un-modified. In the second case, the robot's wheels were taken off. We took off the wheels in the hopes that this would lessen the vibrations of the robot resulting in a more stable position.
+Afterwards, we modified ***GyroTest*** to let both motors run while the program was running, in order to see the effect of the resulting voltage drop. We also added a data logger to the program to gather information for later observations. We used this to calculate the average reading and the average drift, presented in table 2 below. Two cases were investigated: In the first case, the robot was un-modified. In the second case, the robot's wheels were taken off to. We took off the wheels in the hopes that this would lessen the vibrations of the robot resulting in a more stable position.
 
 |             | Average reading | Highest offset | Lowest offset | Upper deviation | Lower deviation |
 | ----------- | --------------- | -------------  | ------------- | --------------- |  -------------- |
@@ -243,27 +244,26 @@ Afterwards, we modified ***GyroTest*** to let both motors run while the program
 There seems to be no significant difference between the robot when whearing weels and when not - there is only a difference of 0.1 between the average readings in the two cases. We concluded that the difference is negligible. 
 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, we were not necessarily wrong in our observation as 598 could simply result from that specific testing situation being an extreme with respect to the average. 
 
-In both cases the readings fluctuate around the average offset and there does not seem to be a clear drift towards neither upper nor lower values (see Figure 7). If testing for a longer duration of time we might expect to see a drift towards lower values as the average deviation in that direction is larger than towards higher values, in both cases. The maximum and minimum offsets measured are the same in both cases, further suggesting that vibrations from the wheels have no significant effect.
+In both cases the readings fluctuate around the average offset and there does not seem to be a clear drift towards neither upper nor lower values (see figure 7). If testing for a longer duration of time we might expect to see a drift towards lower values as the average deviation in that direction is larger than towards higher values, in both cases. The maximum and minimum offsets measured are the same in both cases, further suggesting that vibrations from the wheels have no significant effect.
 
 ![Plot of offset readings from gyro sensor WITH wheels](https://gitlab.au.dk/LEGO/lego-kode/raw/master/week7/img/mhjul.png)
 ![Plot of offset readings from gyro sensor WITHOUT wheels](https://gitlab.au.dk/LEGO/lego-kode/raw/master/week7/img/uhjul.png)
 
 *Figure 7: Plot of readings from the gyro sensor, with wheels (purple) and without wheels (turquoise) - "dev." is short for deviation*
 
-Based on  code presented in [the lesson plan](http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson5.dir/Lesson.html), 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. 
+Based on code presented in [the lesson plan](http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson5.dir/Lesson.html), 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.
 
 ## Conclusion
 (TODO alle: SKRIV MERE KONKLUSION TIL LIGHT SENSOR)
 
-Testing the parameters in a way inspired by grid search provided us with a structured approach to investigating how the different paramters influence each other. Althugh limited time forced us to move on before fully completing an actual grid search, we did obtain some insights into the effect of the parameters on the robot's responsiveness to the light sensor.
+Testing the parameters in a way inspired by grid search provided us with a structured approach to investigating how the different paramters influence each other. Although limited time forced us to move on before fully completing an actual grid search, we did obtain some insights into the effect of the parameters on the robot's responsiveness to the light sensor.
 
 We observed that changes in the angle reflected less strongly in the readings of the color sensor than in those of the light sensor. Our test of this underlined the necessity of interleaving qualitative assessments with quantitative measurements, due to the difficulty of conducting isolated experiments - many different factors influence the results and can sometimes be hard to take into account.
 
 Preliminary experiments with the gyro sensor resulted in a good basis for further investigation into how to make a balancing robot. Sadly, time constraints forced us to finish the lesson before getting to the actual implementation. We may look into the obtained insights in connection with later projects in the LEGO course.
 
-
 ## References
 [1] Philippe Hurbain, [NXTway](http://www.philohome.com/nxtway/nxtway.htm)