... | ... | @@ -148,7 +148,7 @@ To find the best possible setpoint, we followed the procedure described above an |
|
|
| 600 | Too high | Falls forwards |
|
|
|
| 550 | Too low | Falls backwards|
|
|
|
| 580 | Too high | Falls forwards, briefly balancing |
|
|
|
| 570 | Too low | Falls backwards, with less balance than for sp = 570 |
|
|
|
| 570 | Too low | Falls backwards, with less balance than for sp = 580 |
|
|
|
| 575 | OK | Seems to mostly be falling backwards|
|
|
|
| 578 | OK | Pretty good initial balance with no preferred fall-direction|
|
|
|
| 577 | OK | Same as or better than 578 - really hard to tell |
|
... | ... | @@ -157,19 +157,18 @@ To find the best possible setpoint, we followed the procedure described above an |
|
|
|
|
|
Noting that the value measured by the robot initially was around 580, we started with a value of 500 to see the effect. We then tried a value of 750 (simply to try something somewhat in the middle between 500 and the highest possible value of 1023). Seeing how poorly both of these affected the robot's performance, we tried a value of 600 which made the robot perform a lot better. After this, we started narrowing in between 600 and 550, ending at a value of 577. After a while of testing, we noticed that the robot was casting a shade depending on the direction that the light was coming from. This has most likely affected the light readings, but we have not taken this further into account except for the awareness that the accuracy of our measurements need to be taken with a grain of salt. Additionally, the values we arrived at were specific for the exact ambient lighting in the room we were in at the time. Any change in lighting would change the ideal setpoint, and we'd have to do these readings again.
|
|
|
|
|
|
*P value:*
|
|
|
In the code that we used as basis for our own, ***p*** was 28.
|
|
|
Using the grid search approach again, we first tried with 40 (robot falling forward a lot) and 10 (robot corrects too slowly but simply falls forward right away). We then tried 70, in which case the robot also kept falling a lot, but the corrections seemed more aggressive (which makes sense), causing it to oscillate violently.
|
|
|
##### P value
|
|
|
As mentioned, ***p*** is 28 in Bagnall's code.
|
|
|
Using the grid search approach again, we first tried with 40 (robot falling forward a lot) and 10 (robot corrects too slowly and simply falls forward right away). We then tried 70, in which case the robot also kept falling a lot, but the corrections seemed more aggressive (which makes sense), causing it to oscillate violently.
|
|
|
|
|
|
We changed the setpoint to 585 and tried values of p between 40 and 70. As before, 70 caused violent oscillations and instability. Both 55 and 40 seemed more stable. We decided to continue testing with a value of 40.
|
|
|
Additional observation: The robot seems to stop briefly once in a while, usually causing the robot to instantly fall over. This seemed to happen more with p = 70 than with p = 40, and can be seen in video 4.
|
|
|
We changed the setpoint to 585 (based on someone's gut feeling, shame on us) and tried values of *p* between 40 and 70. As before, 70 caused violent oscillations and instability. Both 55 and 40 seemed more stable. We decided to continue testing with a value of 40. We have not included our full table of observations, as it would take up a lot of space considering that we could just as well describe the results verbally.
|
|
|
An additional observation that we made is that the robot seemed to stop briefly once in a while, usually causing it to instantly fall over. This seemed to happen more with *p* = 70 than with *p* = 40, and can be seen in Video 4.
|
|
|
|
|
|
[![Robot motors randomly stopping](http://img.youtube.com/vi/ZMNerUoDBZE/0.jpg)](https://www.youtube.com/watch?v=ZMNerUoDBZE)
|
|
|
|
|
|
*Video 4: Robot motors randomly dead stopping, causing it to fall*
|
|
|
|
|
|
*I value:*
|
|
|
*Video 4: Robot motors randomly stopping dead, causing it to fall*
|
|
|
|
|
|
##### I value
|
|
|
We observed that once the robot started falling in any direction (forwards or backwards) it would generally keep slowly falling in that direction until tipping over (despite also driving in that direction in an attempt to balance). As such, we needed a stronger reaction on past accumulated errors, which is exactly what the integral variable controls, so we experimented with different I-values.
|
|
|
|
|
|
Initially the I-value was 4, and as just explained we needed a stronger reaction on past errors, so we attempted increasing it.
|
... | ... | |