Lesson5.md

@@ -106,9 +106,9 @@ 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 and environment setup. We therefore decided to start testing which specific variables would be best for our setup. 
 
-Note: Camilla & Nicolai: Vi valgte at udlade at vi ændrede ints til floats, fordi vi alligevel caster dem til ints de fleste steder og har svært ved at finde på argumentation for hvorfor det skulle gøres udover "ole said so"
+***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*** 
 
 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.
 
@@ -121,7 +121,7 @@ Later on we noticed that two java programs to use as inspiration were actually p
 
 We ended up writing (basically through capy-paste though) four programs; ***PICcontroller.java***,  ***PCconnection.java***, ***Sejway.java*** and ***NXTSegwayRunner.java***. 
 
-The ***PIDcontroller.java*** is the PC GUI to enable PC control of variables used on the NXT. This program sets up a GUI with six fields and two buttons. The first two fields contains name and bluetooth device ID, which is used when clicking the 'connect'-button, as this action starts NXT communication with the given device ID and sets up a dataOutPutStream [TODO ref].
+The ***PIDcontroller.java*** is the PC GUI to enable PC control of variables used on the NXT. This program sets up a GUI with six fields and two buttons. The first two fields contains name and bluetooth device ID, which is used when clicking the 'connect'-button, as this action starts NXT communication with the given device ID and sets up a dataOutPutStream.
 The last four fields are input fields for *P*, *I*, *D*, and *SP* respectively, where SP is the calibration setpoint that the NXT program will aim for - i.e. its offset. The last variable was added to the PC controller, as we wanted to avoid box-calibration which we suspected didn't entirely remove the button-push error of the calibration. 
 
 The ***PCconnection.java*** is inspired from the ***Tracker.java*** and therefore is responsible for retrieving the parameters send from the pc through the datastream and forwarding them to a running ***Sejway.java*** instance. 
@@ -156,19 +156,9 @@ To find the best possible setpoint we decided to use the PID values of Bagnall's
 
 (Camilla og Nicolai nåede hertil - for nu)
 NOTE: Planen for resten af dette afsnit er: 
-3. Vis (måske - hvis passende) nogle video eksempler
 4. Resultater fra GRID search
 5. konklusioner
 
-
-The robot seemed to fall faster than it corrected  - i.e. we need more motorpower as it falls. 
-We tried to change the i-value - which was 4 initialy
- 
-5: better 
-6: better 
-7: - maybe better 
-8: poorer 
-
 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:*  
@@ -181,8 +171,13 @@ 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. 
  
-***TODO skriv om: TRYING SOMETHING NEW (inspired by the above approach)***
-Strategy: Trying extreme values for each variable to understand the effect of changing it. Then trying empirically to find good parameter values by utilizing this knowledge. 
+***TODO Nicolai: skriv om test af i-værdi***: The robot seemed to fall faster than it corrected  - i.e. we need more motorpower as it falls. 
+We tried to change the i-value - which was 4 initialy
+ 
+- 5: better 
+- 6: better 
+- 7: - maybe better 
+- 8: poorer 
 
 We decided to finish up the experiments (long) before having tried all possible combinations of parameters values, as it seemed pointless to go on when seeing no significant improvements to the robot's behaviour - continuing would not improve on our understanding of the effects of the different PID parameters further. However, the parameter search inspired by grid search did provide us with a more structured insight into the effects of the different parameters than had we just tried varying each parameter on a whim.