Skip to content

Changes

Page history
Test authored by Ivan Grujic's avatar Ivan Grujic
Show whitespace changes
Inline Side-by-side
Lesson-5.markdown
View page @ b6c25bdd
......@@ -221,11 +221,11 @@ An overview of the software architecture for this exercise is seen in the follow
![Software architecture for exercise 3](https://gitlab.au.dk/rene2014/lego/raw/master/Lesson5/Images/GyroSensorSoftware.png)
The controller used for this exercise is inspired by the controller described in [5]. Unlike the previous exercises, this controller is not a regular PID controller, and it monitors two values instead of one; angular velocity and tacho counts of the two motors. The angular velocity is then integrated over time, to obtain the current angle of the robot. The current motor position is calculated as the sum of the tacho count from each motor. The current motor speed is then derived from the position by differentiating the position with regards to time. The controller is thus relying on four terms:
The controller used for this exercise is inspired by the controller described in [5]. Unlike the previous exercises, this controller is not a regular PID controller, and it monitors two values instead of one; angular velocity from the gyrosensor and tacho counts of the two motors. The angular velocity is then integrated over time, to obtain the current angle of the robot. The current motor position is calculated as the sum of the tacho count from each motor. The current motor speed is then derived from the position by differentiating the position with regards to time. The controller is thus relying on four terms:
* **GyroAngle:** This term is responsible for causing the robot to return to the starting position (standing upright). If the robot starts in the upright position, that angle will be 0 degrees. This value will be positive if the robot is leaning forward, and negative if its leaning backward, thus contributing to the control output.
* **GyroSpeed:** This term is non-zero when the robot is accelerating, and thus contributes to the control output when the robot is falling.
* **MotorPosition:** This term is non-zero when the wheels of the robot has turned from the starting point. Thus, this term is responsible for keeping the robot stationary, and is not related to staying upright. This term can be used to drive the robot to a desired location, however we did not exploit this fact in this exercise.
* **MotorPosition:** This term is non-zero when the wheels of the robot has turned from the starting point. This term can be used to drive the robot to a desired location, however we did not exploit this fact in this exercise.
* **MotorSpeed:** This term is non-zero when the wheels of the robot are rotating. This term keeps the robot from oscillating.
Like in the previous exercises a PC connection class is used to establish a Bluetooth connection between the NXT and the PC letting us choose values for the control parameters on the fly.
......@@ -248,7 +248,7 @@ void calcGyroValues(float interval)
}
```
The motor terms `motorSpeed` and `motorPosition` is calculated as shown in the following listing:
The motor terms `motorSpeed` and `motorPosition` are calculated as shown in the following listing:
```java
private void calcMotorValues(float interval)
......@@ -318,9 +318,9 @@ Other similar tests could be performed to test how the environment(temperature,
To test the robot and the different gains effect on the robot, as described in the setup, we tried to control the robot with one gain at a time:
* **KGyroAngle**: Controlling the robot only with the gyro angle, was not possible. The problem encountered was that the angle drifted with time. In the beginning of the test, the angle was correctly 0 degrees when the robot was in an upright position, but during the test this changed to +5-10 degrees. This meant that the robot tried to maintain a position which was not upright, and therefore fell over.
* **KGyroSpeed**: The gyro speed did not drift in the same way as the angle and as a consequent the control using only the gyro speed was much better than the angle, although it was not sufficient for the robot to maintain balance.
* **KGyroSpeed**: The gyro speed did not drift in the same way as the angle and as a consequence the control using only the gyro speed was much better than the angle, although it was not sufficient for the robot to maintain balance.
* **KSpeed**: The motor speed gain determines the resistance in the motor. The faster the wheel was spun, the higher the resistance from the motor.
* **KPos**: The motor position gain makes the wheel turn back to its original position. Increasing the gain increases the speed with which the motor turns back to the set-point. If increased to much, the motors starts oscillating.
* **KPos**: The motor position gain makes the wheel turn back to its original position. Increasing the gain increases the speed with which the motor turns back to the set-point. If increased too much, the motors starts oscillating.
A possible cause for the erroneous angle could be, that the gyro sensor is more sensitive in the forward direction than backwards, causing a small error on each gyro speed calculation, which the integration over time then accumulates.
In the first test of the robot, the gyro sensor was placed on the shoulder of the robot(see the pictures in section "physical setup"). This gave rise to a lot of fluctuations in the gyro sensor data, due to the fact that robots upper part is very loosely connected to the lower part and therefore shakes a lot.
......@@ -330,7 +330,7 @@ In the second part, the gyro sensor was attached to the lower part of the robot.
In this lesson we have performed experiments with various robot constructions and software implementation in order to create a self-balancing robot. We found out that this is not a straight forward task and many external factors plays an important role.
Two sensors, a light and color sensor, was analyzed in a PID control context. With the right surface and the right lighting we were able to make the robot balance for ~25 seconds. However just by introducing natural light the robot was only able to balance for ~2 seconds which is a significantly deterioration. The same applies to the surface where a non-uniform also yields a deterioration. From this we can conclude that when using these types of sensors in a control context the surroundings should be kept in mind.
Two sensors, a light and color sensor, were analyzed in a PID control context. With the right surface and the right lighting we were able to make the robot balance for ~25 seconds. However just by introducing natural light the robot was only able to balance for ~2 seconds which is a significant deterioration. The same applies to the case of a non-uniform surface which also yields a deterioration. From this we can conclude that when using these types of sensors in a control context the surroundings should be kept in mind.
According to our results the color sensor performed better than the light sensor under the same conditions. With a similar output from the sensors we were not able to determine the why the color sensor was superior.
......