... | ... | @@ -4,27 +4,108 @@ |
|
|
|
|
|
**Date:** 17/3 2016
|
|
|
|
|
|
**Group members participating:** Kirstine, Simon, Martin
|
|
|
**Group members participating:** Kirstine, Simon, Martin, Leander
|
|
|
|
|
|
**Activity duration:** ?? hours
|
|
|
**Activity duration:** 2,5 hours + TID BRUGT I DAG
|
|
|
|
|
|
## Goal
|
|
|
|
|
|
In this exercise, our goal is to create a segway-inspired robot which balances on two wheels. To begin with we will try to balance the robot using just a light sensor, then a color sensor and finally we will upgrade the robot to also use a gyro sensor.
|
|
|
|
|
|
## Plan
|
|
|
We intend to follow the plan laid out in the exercise material. First we will build the robot outlined in [1] and try to get it to run the program outlined in [2].
|
|
|
|
|
|
|
|
|
### Self-balancing robot with light sensor
|
|
|
We have built the robot using the guide created by Nathanael Wilson [3] and used the program by Brian Bagnall [2]. It can be seen in figure 1:
|
|
|
|
|
|
|
|
|
![Sejway_front](/uploads/c67a6bfe3240c2d5f3e7d6cf81c38b18/Sejway_front.jpg)
|
|
|
*Fig. 1* The design of the first iteration of the self-balancing robot
|
|
|
|
|
|
|
|
|
We have tried to fulfill the advice given by Phill on environmental conditions as far as possible:
|
|
|
|
|
|
As little light interference as possible: We used a room only lit by fluorescent light (no light didn’t make that big of a difference, but made filming the result harder).
|
|
|
Clear non-uniform surface: We used a table with a little texture and a smooth surface.
|
|
|
NXTway must be perfectly balanced at button press: This is quite tricky, but makes a big difference. We have tried our best to balance the robot and made a countdown until we read the offset so that the button press would not skew the results. Once we read the result we took an average of 20 measurements in order to avoid noise.
|
|
|
|
|
|
These considerations resulted in us making the Sejway.java program, which is built around the Sejway.java file from [2]. We also implemented a data logger in DataLogger.java where we implemented a function for saving an array of values in a csv-file in order to watch how the three different errors in the PID controller changed over time and as a result of the measurements. We quickly realized, however, that logging 4 different variables in every iteration of the control loop was much too taxing on the robot and it slowed down the PID loop a lot. As the PID loop was slowed down it became unreliable and the robot fell over practically immediately. If we removed the data logger write calls, the robot did slightly better and actually attempted to balance.
|
|
|
We solved this problem by saving the first 1000 data points locally in an array and then we wrote them to a file in the shutdown method instead. This enabled us to log the data we needed to make the error plots shown in figure 2 while still not slowing the control loop down to a halt. A plot of the light sensor values is shown in figure 3 and a video of the attempt can be seen in [6].
|
|
|
|
|
|
![Sejway_error_plot](/uploads/61cbaad4b072e2198676975200610024/Sejway_error_plot.png)
|
|
|
*Fig. 2* Plot of the Sejway errors
|
|
|
|
|
|
![Sejway_light_value](/uploads/e1ced277cb96da59baa62612fd7b41ce/Sejway_light_value.png)
|
|
|
*Fig. 3* Plot of Sejway light sensor values
|
|
|
|
|
|
|
|
|
During our testing with the light sensor, we experienced trouble with balancing the robot and especially the robot had trouble recovering with even the slightest off-balance. In order to counter this we experimented with adjusting the offset based on measurements from the tacho counter. The intuition behind the experiment was that a slight imbalance in the initial offset measurement would make the robot drive in a particular direction and this would result in the tacho counter increasing or decreasing. We extended the Sejway.java program with additional logic in order to exploit this where we simply adjusted the light sensor offset in the opposite direction of the way the robot was driving, but the two control systems seemed to be unable to work together. In fact our observation was that the two systems attempted the same thing, namely to make the robot stand still and as their efforts were aligned they made the robot overcompensate instead. After spending some time trying to tweak the PID values as well as the tacho-counter-induced offset we decided to move away from the idea and look towards improving the physical design instead.
|
|
|
|
|
|
We suspected the reason for the poor balancing skills to be the structure of the robot with a low center of gravity, so to counter the problems we created the “Segway with rider” model [4]. To make sure we have consistent data without other variables than the sensors, we remade the light-sensor experiment with the new robot.
|
|
|
|
|
|
Results from the “Segway with rider” with the light sensor are shown in the graphs below (figure 3 and 4):
|
|
|
|
|
|
### Self-balancing robot with light sensor
|
|
|
![Sejway_new_robot_light_value](/uploads/14496c008d68c0230824e96ac1e1fdcb/Sejway_new_robot_light_value.png)
|
|
|
*Fig. 3* The light values measured on the “Segway with rider” robot
|
|
|
|
|
|
![Sejway_new_robot_error_plot](/uploads/353a4a880cbf71cf0d9b8789ae74709d/Sejway_new_robot_error_plot.png)
|
|
|
*Fig. 4*
|
|
|
|
|
|
|
|
|
Even without changing the PID values, the new robot is already better at balancing from the beginning [5].
|
|
|
|
|
|
[SKRIV KONKLUSION HER]
|
|
|
|
|
|
### Self-balancing robots with color sensor
|
|
|
Switching to the color sensor, still using the “Segway with rider” model, we implemented changes to the program in order to use the color sensor.
|
|
|
The new robot design can be seen in figure 5.
|
|
|
|
|
|
![gyro-side-2](/uploads/161ae6f28d19847ef1235b0ac9048141/gyro-side-2.jpg)
|
|
|
*Fig. 5* A robot guy on a NXT segway
|
|
|
|
|
|
We implemented the new SejwayColor.java program based on the Sejway.java program from earlier.
|
|
|
|
|
|
In order to tune the new robot we tried to use the "Ziegler–Nichols Method" [8] again in order to get better constants. We first set the integral and the differential constants to 0 and tried to make a balancing robot with just a proportional control. After fiddling around with the values we found that a Kp value of 3.0 worked remarkably well and actually balanced the robot for a fairly long time. Trying to implement the Integral value as a PI-controller, we needed to calculate the KI-value. We measured the oscillation time to be around 0.25 s and we know from our data logger that the runtime of the internal control loop is 4ms. This gives us the following values:
|
|
|
|
|
|
dT = ca 4 ms
|
|
|
Kc = 3.0.
|
|
|
Pc = ca 250 ms
|
|
|
Kp = 1.35
|
|
|
Ki = 0.026
|
|
|
|
|
|
We used these values to calculate the KI-value for our PI-controller using the formula KI=1.2K<sub>p</sub>dT/ P<sub>c</sub> = 0,026.
|
|
|
|
|
|
Using the calculated values, we found the robot to be very stable when first balanced. The result can be seen in the video [10]. We decided against trying to calculate a Kd value since the precision for the error measurements are so low. As we can see in figure 2 we more often than not have a differential error of 0, and this makes the measurement a bit problematic.
|
|
|
|
|
|
|
|
|
### Self-balancing robots with gyro sensor
|
|
|
Using the GyroTest.java program [7], we found that the gyro value when stationary, also known as the offset, was around 600 ±5. We have mounted the sensor in such a way that tilting the robot backwards makes the gyro twist in a clockwise direction, and thereby raising the value of the sensor, while moving. Turning it the other way results in a lower reading.
|
|
|
The placement of the gyro can be seen in figure 6.
|
|
|
|
|
|
|
|
|
## Conclusion
|
|
|
![gyro-side](/uploads/a11572cc925f88b46a2ef4b5548c74b4/gyro-side.jpg)
|
|
|
*Fig. 6* The placement of the gyro
|
|
|
|
|
|
## References
|
|
|
|
|
|
In order to get a good measure to balance our robot against we used the angle calculated in the way outlined in [9]. Using the angle as the error value in the Proportional controller, we tried to balance the robot. However, we found that it was difficult to compensate for the gyro drift. By lowering the offset on each iteration, we tried to compensate for the drift. That didn’t help much since it resulted in that if the robot was tilted, the compensation quickly made the robot think it was in an upright position, stopping the motors and making it fall over.
|
|
|
|
|
|
We suspect that the drift is somewhat caused by variation in the voltage because the gyro sensor is affected by small changes in the input voltage, as suggested in [11]. Starting the motors will result in a slight power drop and thereby change the drift.
|
|
|
|
|
|
Link to this page: https://gitlab.au.dk/lego15/NXT_Programming_Lesson_5/wikis/home |
|
|
\ No newline at end of file |
|
|
## Conclusion
|
|
|
In this exercise we have built and programmed two different Segway-inspired robots. The first robot was a bottom heavy robot which only used a light intensity sensor in order to balance. The robot only managed to balance for a few seconds at a time and we performed several experiments in order to improve this. First we noticed the difference made by using a better environment for our experiments, which we performed in a closed room lit only by fluorescent lights. Next we tried to adjust the balancing offset based on the tacho counter inside the two motors, but this turned out to have limited applicability. The robot was controlled by a PID-controller with recommended weights throughout these experiments.
|
|
|
Next we improved the physical design of the robot to a more top-heavy variant and we exchanged the light intensity sensor for a color sensor instead. After a few failed experiments we decided to remove the integral and differential parts of the PID while just concentrating on the proportional control. This new design coupled with a fine-tuned proportional controller gave us our best results with a robot which was able to balance for a long time without outside intervention. Re-adding the integration part of the controller made no noticeable difference to the robot’s performance.
|
|
|
Lastly we tried to implement a balancing robot with a gyro sensor instead of the light based sensor from previous experiments. We had no success with getting this to work and the performance of the robot with this sensor never reached that of the robot with the light sensor.
|
|
|
|
|
|
## References
|
|
|
[1] Philippe Hurbain, NXTway.
|
|
|
[2] Brian Bagnall, Maximum Lego NXTBuilding Robots with Java Brains, Chapter 11, 243 - 284.
|
|
|
The chapter contains a java program Sejway.java that can be used as a starting point for experiments with a self-balancing LEGO robot.
|
|
|
[3] http://www.philohome.com/nxtway/bi_nxtway.htm
|
|
|
[4] http://www.nxtprograms.com/NXT2/segway/index.html
|
|
|
[5] https://goo.gl/xM2bsJ
|
|
|
[6] https://goo.gl/sl94bk
|
|
|
[7] http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson5.dir/Lesson5Programs/GyroTest.java
|
|
|
[8] http://www.inpharmix.com/jps/PID_Controller_For_Lego_Mindstorms_Robots.html
|
|
|
[9] http://www.hitechnic.com/blog/gyro-sensor/htway/
|
|
|
[10] https://goo.gl/yIbKaK
|
|
|
[11] https://nxttime.wordpress.com/2013/04/19/the-gyro-sensor/ |