Group_6_Lab_Session_5.markdown

@@ -11,7 +11,7 @@ In this lab session we will try to create a self-balancing robot, using differen
 In this section, we replicate the robot from Philippe Hurbain's construction [1], in an attempt to make it balance by itself. The roboto will balance by adjusting the motor-power, based on the light sensor readings. 
 
 ### Setup & Approach
-The only difference between Phillippe's and our robot is that we are using the big battery pack, where Philippe is using the AA-battery pack. This required us to change the cross-beam behind the robot very slightly. Other than that, the robots are similar. On the following 6 pictures we see the robot and our testing environment. The first image shows our lighting situation, where we closed the curtains to rely on flourescent light only. This was suggested by Philippe Hurbain, in the section "Usage" [1]. Images 2-5 shows the robot with a table as the sensed surface (where the light emits from). In the last image, we've used a piece of white cardboard as our surface, to test Phillipe's other suggestion, that contoured/non-uniform and clean surfaces work the best. We expected the white surface to reduce performance, since it is too uniform.  
+The only difference between Phillippe's and our robot is that we are using the big battery pack, where Philippe is using the AA-battery pack. This required us to change the cross-beam behind the robot slightly. Other than that, the robots are similar. On the following 6 pictures we see the robot and our testing environment. The first image shows our lighting situation, where we closed the curtains to rely on flourescent light only. This was suggested by Philippe Hurbain, in the section "Usage" [1]. Images 2-5 shows the robot with a table as the sensed surface (where the light emits from). In the last image, we've used a piece of white cardboard as our surface, to test Phillipe's other suggestion, that contoured/non-uniform and clean surfaces work the best. We expected the white surface to reduce performance, since it is too uniform.  
 
 ![Figure 1](http://i.imgur.com/gdmdcOlm.jpg)
 ![Figure 2](http://i.imgur.com/BbSqwqfm.jpg)
@@ -152,9 +152,58 @@ We use [these building instructions](http://robotsquare.com/2012/02/12/tutorial-
 ![Figure 14](http://i.imgur.com/DjmE0r4m.jpg)
 ![Figure 15](http://i.imgur.com/JVMYXDEm.jpg)
 
+### Findings
+
+We had a lot of trouble implementing the PID using the Gyro Sensor. We only achieved a few seconds of balance time, as seen in this video: [PID Short Balance]().
+
+After hours of trial-and-error with our own PID we decided to explore alternatives. We tried to replicate the control system used in the HTWay [9]. The full source code can be seen here: [SegwayGyro.java](https://www.dropbox.com/s/allwymb30bd4vl1/SegwayGyro.java?dl=0).
+
+We tried adjusting the balancing constants and achieved steady balancing for several minutes, as can be seen in the following two videos, notice the sweet training wheels!
+
+**[Segway Balancing with Gyro Sensor 1](http://1drv.ms/1CdVXTB)**
+
+**[Segway Balancing with Gyro Sensor 2](http://1drv.ms/1CdW5Cl)**
+
+In these experiments we used the following balancing constants:
+
+````java
+KGYROANGLE = 30
+KGYROSPEED = 3
+KPOS = 0.2
+KSPEED = 0.1
+````
+
+In our case it was essential to increase the weight of the motor angle to compensate for the Gyro's errors. In addition, we learned that the initial offset estimation is crucial, which is why we increased the number of samples from 100 to 250, which also increased stability.
+
+The HTWay solution implements an Estimated Moving Average (EMA) to smoothen the offset (low-pass filter), as described in the "Integration"-section [9]. The implementation of the low-pass filter is as follows:
+
+````java
+  public static double EMAOFFSET = 0.0005;
+  ....
+  float gyroRaw;
+
+  gyroRaw = SensorHTGyro(GYRO);
+  gOffset = EMAOFFSET * gyroRaw + (1-EMAOFFSET) * gOffset;
+  gyroSpeed = gyroRaw - gOffset;
+
+  gAngleGlobal += gyroSpeed*tInterval;
+  gyroAngle = gAngleGlobal;
+````
+
+The EMA offset is very small, but will have an effect over longer periods of time, which would apply in our case. But even with this smoothing, the Gyro shows a minor drift, which can be seen in the figure below. We sampled the raw Gyro Sensor-data for approximately 40 seconds (not longer because of memory consumption) and plotted it in Excel. 
+
+![Imgur](http://i.imgur.com/YcKdV16.png)
+
+This may suggest, that even though our videos show 3 minutes of balancing, it may be yet be limited. Even though we increased our samples when estimating the gyro offset, we might want to use even more samples to account for battery drain and temperature shifts. 
+
+In addition, the Gyro Sensor is not positioned directly over the wheel axis, which may also influence the reaction time. However, since we're using an upright NXT brick as our robot's base, the Gyro Sensor's sensitivity is increased because of the longer arm (distance to wheel axis). 
+
+As a final note, we tried changing the wheels on the robot to the NXT 2.0 wheels (middle size) which significantly decreased the smoothness of the balancing. The wheels seemed to be warped when changing directions, making the entire construction a bit shaky. This was not the case with the smaller wheels we initially used. 
+
 ## Conclusion
 
 
+
 ### References
 * [1], [Philippe Hurbain](http://www.philohome.com/nxtway/nxtway.htm)
 * [2], [Sejway.java](http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson5.dir/Lesson5Programs/Sejway.java)