... | @@ -82,9 +82,9 @@ In the datalogger class we had to replace FileOutputStream with BufferedOutputSt |
... | @@ -82,9 +82,9 @@ In the datalogger class we had to replace FileOutputStream with BufferedOutputSt |
|
>During the testing of our robot we used the GUI (see fig. ??) to adjust the PID values as well as the offset and SCALE values. We found it necessary to be able to adjust the offset as the value would change a little just by clicking the enter button for the selection.
|
|
>During the testing of our robot we used the GUI (see fig. ??) to adjust the PID values as well as the offset and SCALE values. We found it necessary to be able to adjust the offset as the value would change a little just by clicking the enter button for the selection.
|
|
>
|
|
>
|
|
> ![PID_gui](http://gitlab.au.dk/uploads/group-22/lego/56fed5f205/PID_gui.png)
|
|
> ![PID_gui](http://gitlab.au.dk/uploads/group-22/lego/56fed5f205/PID_gui.png)
|
|
> ##### Fig. 4 - Control GUI used to adjust the PID values as well as offset (o) and SCALE (s).
|
|
> ##### Fig. 5 - Control GUI used to adjust the PID values as well as offset (o) and SCALE (s).
|
|
>
|
|
>
|
|
> While using the GUI we ran into a problem where the values would not be sent correctly to the robot. Instead of just sending one value for the P parameter all the values would change to the same as the P value. We think the problem lies in the PCcarController.java program. In the part of the program that sends the values to to robot, we had forgot to change the I value from an int to a float value (see fig. 5). After fixing this the Bluetooth connection seemed to work normally again.
|
|
> While using the GUI we ran into a problem where the values would not be sent correctly to the robot. Instead of just sending one value for the P parameter all the values would change to the same as the P value. We think the problem lies in the PCcarController.java program. In the part of the program that sends the values to to robot, we had forgot to change the I value from an int to a float value (see fig. 6). After fixing this the Bluetooth connection seemed to work normally again.
|
|
>
|
|
>
|
|
>```
|
|
>```
|
|
> try
|
|
> try
|
... | @@ -115,7 +115,7 @@ In the datalogger class we had to replace FileOutputStream with BufferedOutputSt |
... | @@ -115,7 +115,7 @@ In the datalogger class we had to replace FileOutputStream with BufferedOutputSt |
|
> dos.flush();
|
|
> dos.flush();
|
|
> }
|
|
> }
|
|
>```
|
|
>```
|
|
> ##### Fig. 5 - Code from the PCcarController.java program where the I value needed to be changed to fix a bluetooth connection problem.
|
|
> ##### Fig. 6 - Code from the PCcarController.java program where the I value needed to be changed to fix a bluetooth connection problem.
|
|
>
|
|
>
|
|
>---
|
|
>---
|
|
>
|
|
>
|
... | @@ -152,10 +152,10 @@ In the datalogger class we had to replace FileOutputStream with BufferedOutputSt |
... | @@ -152,10 +152,10 @@ In the datalogger class we had to replace FileOutputStream with BufferedOutputSt |
|
>
|
|
>
|
|
> From the NXT time blog, we know that gyro sensors measure how fast that they are rotating [9], ie degrees of angle per second. Therefore it cannot know which way it is currently facing, just that it is either still, or moving in a certain direction.
|
|
> From the NXT time blog, we know that gyro sensors measure how fast that they are rotating [9], ie degrees of angle per second. Therefore it cannot know which way it is currently facing, just that it is either still, or moving in a certain direction.
|
|
|
|
|
|
> We figured that If the distance from the sensor to the center of gravity of the robot is large, the gyro sensor will have a wider path to swing, making the values larger, as can be seen in (fig. 6).
|
|
> We figured that If the distance from the sensor to the center of gravity of the robot is large, the gyro sensor will have a wider path to swing, making the values larger, as can be seen in (fig. 7).
|
|
>
|
|
>
|
|
>![Gyro sensor udsving (1)](http://gitlab.au.dk/uploads/group-22/lego/b48fa6e6d9/Gyro_sensor_udsving__1_.jpg)
|
|
>![Gyro sensor udsving (1)](http://gitlab.au.dk/uploads/group-22/lego/b48fa6e6d9/Gyro_sensor_udsving__1_.jpg)
|
|
> ##### Fig. 6: Swing path of gyro sensor.
|
|
> ##### Fig. 7: Swing path of gyro sensor.
|
|
>
|
|
>
|
|
> We ran the GyroTest class to examine the readings of the gyro sensor. The default sensor reading (raw value) when stationary was about 611-612 on a scale from 0 to 1024. By shaking the robot hard, we could get the minimum reading down to 184, and the maximum reading up to 1003. It was hard to read the on screen values of the gyro sensor when the robot was going, so we tried implemented the data logger to get some more accurate readings. NOPE?
|
|
> We ran the GyroTest class to examine the readings of the gyro sensor. The default sensor reading (raw value) when stationary was about 611-612 on a scale from 0 to 1024. By shaking the robot hard, we could get the minimum reading down to 184, and the maximum reading up to 1003. It was hard to read the on screen values of the gyro sensor when the robot was going, so we tried implemented the data logger to get some more accurate readings. NOPE?
|
|
>
|
|
>
|
... | @@ -167,6 +167,20 @@ Desuden kan lav spænding på batteriet også påvirke gyroens offset. |
... | @@ -167,6 +167,20 @@ Desuden kan lav spænding på batteriet også påvirke gyroens offset. |
|
>
|
|
>
|
|
>---
|
|
>---
|
|
>
|
|
>
|
|
|
|
> ## Additional goal - An explanation of the balance theory
|
|
|
|
>
|
|
|
|
> Physical structure of small robot from exercise 1:
|
|
|
|
The robot’s struggle to balance can be due to it’s centre of gravity. As shown in (fig. ?) the robot used for this exercise (placed on the right) has a tall centre of gravity indicated by the horizontal line. We found the centre of gravity by balancing the robots to find their pivot points. Because of this inaccurate method, the centre of gravity might be slightly different if we made the appropriate mathematical calculations, but as the figure only serves as an illustration we found our method adequate.
|
|
|
|
>
|
|
|
|
> ![centre-of-gravity-robots (1)](http://gitlab.au.dk/uploads/group-22/lego/3d98c9c591/centre-of-gravity-robots__1_.jpg)
|
|
|
|
>
|
|
|
|
> One the most important factor with balancing the robots in one axis is the inverted pendulum problem.This means that the robot has its center of mass higher than its pivot point. On our robot the pivot point is the center of the wheels and while the robot is standing, the weight is distributed on top of that pivot point. Because of this, the robot is constantly unstable and the wheels have to correct for the instability. Theoretically the further away the center of mass is from the pivot point, the more stable it should be. An example of this theory is easily observable by trying to balance a broom on a finger; it is much easier to balance it when the head is on top, as the weight is higher on the other side(right side) of the pivot point as seen in fig. kost.
|
|
|
|
>
|
|
|
|
> ![de7438cb-bbeb-43c1-9240-79e1e64a6ad0](http://gitlab.au.dk/uploads/group-22/lego/86adb8ce21/de7438cb-bbeb-43c1-9240-79e1e64a6ad0.gif)
|
|
|
|
>
|
|
|
|
> In our experiments with the two different robots we have found that the Segway segway was much more stable while performing both experiment 1 & 3, than the legway robot. Our initial thoughts were that a robot with a vertically low center of mass would be more stable, as the wheels only would need to correct a small bit. But this was disproven both by the experiments and the physics involved in the inverted pendulum. The problem with having a center of mass close to the pivot point is that when the robot tilts just a tiny bit, it’s easy for wheels to over correct the error and make it even worse. This is because the short distance between the pivot point and the center of mass is easy to oversteer. Additionally the detection the tilt will be harder as the robot would fall faster. This is easier when the distance between the two points are longer.
|
|
|
|
>
|
|
|
|
>
|
|
>
|
|
>
|
|
> ## Conclusion
|
|
> ## Conclusion
|
|
>
|
|
>
|
... | | ... | |