Group_6_Lab_Session_5.markdown

@@ -8,7 +8,7 @@
 In this lab session we will try to create a self-balancing robot, using different sensors as input. These will include a light sensor, a color sensor, and a gyro sensor. Our experimentation and exploration is inspired by Phillippe Hurbain, Brian Bagnall, and Steve Hassenplug.
 
 ## Self-balancing robot with light sensor
-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. 
+In this section, we replicate the robot from Philippe Hurbain's construction [1], in an attempt to make it balance by itself. The robot 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 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.  
@@ -32,10 +32,10 @@ We were able to make it balance for a few seconds 1-4, depending on the initial
 
 **The performance can be seen in this video: [Self-balancing robot with light sensor - Control](http://1drv.ms/1EFIphV)**
 
-We noticed that if the robot titled forward all the way, it had no chance of recovering. The same was the case if it tilted too far backwards. In addition, the light settings in the room (even in this small area) may not be uniform. Thus, what may be equillibrium at one point, may not be in another. However, we weren't able to reduce the light pollution in the room any further.
+We noticed that if the robot tilted forward all the way, it had no chance of recovering. The same was the case if it tilted too far backwards. In addition, the light settings in the room (even in this small area) may not be uniform. Thus, what may be equillibrium at one point, may not be in another. However, we weren't able to reduce the light pollution in the room any further.
 
 #### White Cardboard Surface
-Challenging the advice Phillippe Hurbain we tried to change the surface on which we are sensing (see image 6 in the above gallery). As expected, the performance was even worse and the robot showed very aggressive corrections, which may indicate that the light sensor may have zeroed on something. 
+Challenging the advice Phillippe Hurbain we tried to change the surface on which we sense (see image 6 in the above gallery). As expected, the performance was even worse and the robot showed very aggressive corrections, which may indicate that the light sensor may have zeroed on something. 
 
 **This behavior can be seen in this video: [Self-balancing robot with light sensor - Cardboard](http://1drv.ms/1EFIGRZ)**
 
@@ -58,7 +58,7 @@ Instead of focusing solely on the software parameters of the configuration we tr
 
 **The performance can be seen in this video: [Self-balancing robot with light sensor - Balance Bar](http://1drv.ms/1NfFO2W)**
 
-It's clear that the performance is still not significantly improved, but qualitatively, the balance point was easier to locate and the robot seemed to be more steady. We hope that by combining the balance bar with optimized PID constants, we can imporve the balance time.
+It's clear that the performance is still not significantly improved, but qualitatively, the balance point was easier to locate and the robot seemed to be more steady. We hope that by combining the balance bar with optimized PID constants, we can improve the balance time.
 
 #### Balance Bar and Optimized PID Constants
 In this experiment we combine the above two experiments in an attempt to increase performance. Through trial-and-error we experimented with different values by editing the Java class, compiling it, and transfering it to the robot. 
@@ -78,6 +78,8 @@ Afterwards, we tried with these constants without the balance bar which greatly
 
 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.
 
+As noted the environment is an important factor, and we were about to test our robot in a dark room with no light and on a white surface, to avoid light polution, as advised by our fellow students, however our robot ran out of power, so we had to abandon the experiment. 
+
 ## Choice of parameters on-the-fly
 
 Instead of having to manually alter the source code, compile it, and upload it to the NXT, we can create a GUI that will allow us to do this more efficiently on-the-fly, for faster debugging and experimentation. 
@@ -88,7 +90,7 @@ As a source of inspiration and initial code setup, we use the example [PCcarCont
 
 ## Self-balancing robot with color sensor
 
-In this section we will try to use a color sensor instead of the light sensor, as proposed by the NXT Segway with Rider design [6]. We will use the color sensor to try to infer the relative tilt of the our robot, and use it as input to a PID control system. We hope to achieve similar results as show in this video: [NXT Segway with Leaning Pilot](https://www.youtube.com/watch?v=q9ZONn3p1LI). 
+In this section we will try to use a color sensor instead of the light sensor, as proposed by the NXT Segway with Rider design [6]. We will use the color sensor to try to infer the relative tilt of the our robot, and use it as input to a PID control system. We hope to achieve similar results as shown in this video: [NXT Segway with Leaning Pilot](https://www.youtube.com/watch?v=q9ZONn3p1LI). 
 
 ### Setup & Approach
 
@@ -123,22 +125,22 @@ Scale = 18
 
 The offset is very circumstantial and is pointless to provide. 
 
-This setup allowed a best-case balancing time of XXASASFAS seconds.
+This setup allowed a best-case balancing time of only a couple of seconds.
 
 The setup differentiates from our first experiements in terms of wheel size. The ones used in the experiment are smaller and flatter. We suspected that they would increase stability but were not able to exceed the performance of the light sensor robot. 
 
 We had luck with different combinations of the PID constants, but nothing that was lasting.
 
-Attaching the balance bars could prove to be better but our preliminary tests were only somewhat succesful. 
+Attaching the balance bars could prove to be better but our preliminary tests were only somewhat succesful. The balance bars' primary benefit is us being able to provide the robot with a good starting point, this ability arises from the balance bars widening the robot, thus making it easier to find the balance point, or close to it. 
 
-To sum up, we can conclude that the color sensor was no significant improvement compared to the light sensor, when used as a lightsensor. However, our lighting conditions were nowhere near perfect and due to time limitations we abandoned further experiments. 
+To sum up, we can conclude that the color sensor was no significant improvement compared to the light sensor, when used as a lightsensor. However, our lighting conditions were nowhere near perfect and due to time limitations we abandoned further experiments. One should note that the physical setup of the robot in our experiements with the two sensors were different. The "rider" model, however did not seem to affect the robots ability to balance, but we cannot know for sure as we neglected testing this. 
 
 ## Self-balancing robots with gyro sensor
 Based on RobotSquare's [8] and HiTechnic's documentation [9], we will try to implement our own balancing robot using a Gyro Sensor.
 
 ### Setup & Approach
 
-As an initial study, we will use the test class [GyroTest.java](http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson5.dir/Lesson5Programs/GyroTest.java) to get familiar with the Gyro Sensor's behavior.
+As an initial study, we will use the test class [GyroTest.java](http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson5.dir/Lesson5Programs/GyroTest.java) to get familiar with the Gyro Sensor's behavior. We used the class to realize how the gyro works and to experiement with its reaction to various physica movements.
 
 Afterwards, we will try to apply our findings and use the Gyro Sensor's values as input to the PID controller.
 
@@ -154,12 +156,14 @@ We had a lot of trouble implementing the PID using the Gyro Sensor. We only achi
 
 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!
+We tried adjusting the balancing constants and achieved steady balancing for several minutes, with no indication that it would fall, as can be seen in the following two videos, notice the sweet training wheels we provided it to ensure the NXT would not be damaged!
 
 **[Segway Balancing with Gyro Sensor 1](http://1drv.ms/1CdVXTB)**
 
 **[Segway Balancing with Gyro Sensor 2](http://1drv.ms/1CdW5Cl)**
 
+The gyro is dependent on the temperature of the room, and having heated up the project room we were working in the gyro had a relatively high temperature during our experiments. We tried having the robot balance and then open the door, to have cool air flowing in the room. This did not seem to affect the gyro as the robot was continually balancing. Thus we can with probable cause conclude that a change of temperature in the amount of 3-5 degrees is not a problem - it could be interesting to evaluate the gyro performance when situated outside(~10 degrees). 
+
 In these experiments we used the following balancing constants:
 
 ````java
@@ -169,7 +173,7 @@ 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.
+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. We considered using even more samples however when experiementing with 500, the calibration never ended, indicating that our gyro consistenty got error reading resulting in our sampling to start over. We know that other groups have been sampling way more succesfully, so this may be an issue with our specific gyro.
 
 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:
 
@@ -186,19 +190,26 @@ The HTWay solution implements an Estimated Moving Average (EMA) to smoothen the
   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. 
+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. This drift may be caused by the battery level dropping, and the "battle" for power between the gyro and the motors, this could be investigated further with the use of 3 engines running at full speed, and then test the gyro performance. However we could not do this in time. 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. 
+This may suggest, that even though our videos show 3 minutes of balancing, it may 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. 
+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. Additionally the wheels have a different sizes, thus the distance travelled for one motor round is longer with the larger wheels. This is handled by the gyro, as the changes is distance travelled directly impacts the gyro angles, thus eliminating the size of the wheels as a significant error source.   
 
 ## Conclusion
 
+The result of lab session 5, is that we were able to somewhat balance a NXT with the use of a light-, Color-, and almost perfectly using a gyro-sensor. 
+First test we conducted was with the light sensor which made us able to balance the NXT for several seconds and by adjusting the PID values: KP, KI,KD, and Offset we were able to find suitable settings for our case. We could through further adjustments of the PID values perhaps have found setting with better result. 
+We also concluded that by altering the NXT setup by including a balance bar which made it easier for the NXT to find the balance point.   
+The second experiment was with color sensor we change the setup slightly by trying to investigate the importance of a lower balance point.  We again tried to find the perfect PID values which suited this robot build, and by using a GUI through Bluetooth we were able to change the settings much faster compared to the first experiment. We found that the color sensor was no improvement compared to the light sensor. We could have investigated the PID constants even further, which could lead to a better result.      
+
+Our experiments with the gyro resulted in us realizing that the gyro has a small amount of drift, which makes the use of PIDs very hard, and our best case using our own PID was around 2 seconds. Rewriting a C program found online, which takes care of the drift using tacho counters and a low pass filter we got our robot balancing beautifully.
 
+A general thing to note for all of the experiments we did is the impact of environment and the physical build of the robot. Light pollution and bad choice of surface can hugely affect the readings from both light and color sensor. We used the rider build for our test with the color sensor, looking back we should have used the same build to properly be able to compare the performance of the sensors. On the subject of physical build, we also identified a significant difference in shakiness between the two types of wheels we used, which we can benefit from in later lab sessions.
 
 ### References
 * [1], [Philippe Hurbain](http://www.philohome.com/nxtway/nxtway.htm)