Group_6_Lab_Session_5.markdown

@@ -21,7 +21,7 @@ The only difference between Phillippe's and our robot is that we are using the b
 ![Figure 5](http://i.imgur.com/8QZmA9Gm.jpg)
 ![Figure 6](http://i.imgur.com/wvv8Il0m.jpg)
 
-To make it balance, we adopted Brian Bagnall's control system, [Sejway.java](http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson5.dir/Lesson5Programs/Sejway.java) [2]. Here, however, we tried out different settings and constant values. Which we will specify during our experiments. 
+To make it balance, we adopted Brian Bagnall's control system, [Sejway.java](http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson5.dir/Lesson5Programs/Sejway.java) [2], which was later modified by Ole Caprani. Here, however, we tried out different settings and constant values. Which we will specify during our experiments. 
 
 ### Findings
 
@@ -42,23 +42,16 @@ Challenging the advice Phillippe Hurbain we tried to change the surface on which
 #### Experimenting with PID Constant Values
 The native constants of Brian Bagnall's PID, allowed the robot to balance for a few seconds, which we didn't find satisfying. Through trial-and-error we've narrowed in on the following constants, which gave us increased performance:
 
-**Power = XXXX**
+**Power = 40** (proportional error values).
 
-This forces the robot to correct its errors fast enough, and avoid tilting over as often as the native values.
+**Integral = 10** (accumulating errors)
 
-**Integral = XXXX**
+**Differential = 40** (change in error over time)
 
-This handles accumulating errors by increasing the error value for each consecutive error.
+**Scale = 18** (direct scaling of the entire error value, can be useful with different battery levels)
 
-**Differential = XXXX**
 
-If we are experiencing accelerating errors we correct accordingly. Thus, if we are lowering our error, the acceleration (differential) will be negative and the corrections will get smaller.
-
-**Scale = XXXX**
-
-The scale factor is a simple mapping between the sensor values and the output variables, which changes the optimal dimensions of the constants. Thus, if we change the Scale, then we have to adjust the Power, Integral, and Differential factors accordingly.  
-
-**The performance can be seen in this video: [Self-balancing robot with light sensor - PID Constants](http://1drv.ms/1xgumlG).**
+**The performance can be seen in this video: [Self-balancing robot with light sensor - PID Constants](http://1drv.ms/1EFIphV).**
 
 The robot was able to balance for a few seconds using this configuration. However, it is still not satisfying.
 
@@ -84,6 +77,8 @@ Finally, we made it balance for a whole 17 seconds! In this case, we used the ba
 
 **This performance can be seen in this video: [Self-balancing robot with light sensor - Balance Bar + Optimized PID Constants](http://1drv.ms/1EFRebE)**
 
+Afterwards, we tried with these constants without the balance bar which greatly reduced the performance - it could barely stand up for half a second.
+
 To sum up, we can conclude that the balance bar made it easier to find the balance point and that playing around with the PID constants plausibly increased performance. However, the significant improvement was introduced by combining these sources of improvement, which resulted in a best-case test of 17 seconds of self-balancing. Nonetheless, there are still many more physical aspects to explore, e.g. lowering the balance point, adding more weight instead of the wheels, using bigger wheels, etc.. Further experiments with the PID constants could also improve performance. 
 
 ## Choice of parameters on-the-fly
@@ -92,7 +87,7 @@ Instead of having to manually alter the source code, compile it, and upload it t
 
 As a source of inspiration and initial code setup, we use the example [PCcarController.java](legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson5.dir/Lesson5Programs/PCcarController.java) [3], which creates an initial GUI, initiates the NXT Communication facilities, and the required data input-output handling (over a Bluetooth connection). The code has to be altered to fit our needs. The full source code can be found in [PCbalancerController.java]() [4] and [BTcontrolledBalancer.java]() [5]. Below is a screendump of the GUI.
 
-![Figure 7](GUI SNIPPET LINK)
+![Figure 7](http://i.imgur.com/SRpbyHLl.png)
 
 ## Self-balancing robot with color sensor
 
@@ -100,7 +95,7 @@ In this section we will try to use a color sensor instead of the light sensor, a
 
 ### Setup & Approach
 
-In the first experiment with the color sensor we continue to use the robot we built for the first experiments, but exchanging the sensor. For further experiments, we will try to change the physical properties of the robot, by replicating the lower part of the robot, shown in the video above. I.e., we will follow the [building instructions](http://www.nxtprograms.com/NXT2/segway/steps.html) up to and including step 7 [7]. However, we will not be interlocking the wheels, since our PID applies different levels of power to each engine. Conclusively, they have to be able to run independantly. In addition, we added some minor pieces to the sensor mount, to increase stability and even out the weight distribution slightly.
+In the first experiment with the color sensor we continue to use the robot we built for the first experiments, but exchanging the sensor. For further experiments, we will try to change the physical properties of the robot, by replicating the lower part of the robot, shown in the video above. I.e., we will follow the [building instructions](http://www.nxtprograms.com/NXT2/segway/steps.html) up to and including step 7 [7]. 
 
 Below we see three images of Philippe Hubrain's robot with the Color Sensor, and three images of our NXT Segway.