| ... | ... | @@ -104,11 +104,9 @@ At this point in time, we realized that a GUI for transmitting motor power - and |
|
|
|
| 55 | Movement, but too small angle |
|
|
|
|
| 60 | Movement, seems ok, but turns in opposite direction of light and keeps moving after last check |
|
|
|
|
|
|
|
|
From these small motor power value experiments we realised several flaws of our program. Firstly we had inverted the motor powers and thought that forward ment moving the sensor left and vice versa. This however wasn't the case and we switched the motor directions in all cases. Secondly we didn't stop the motor after trying to reposition the sensor at the original position, which ment that it just kept going to the left until a new light registretion was initiated by the follow behavior.
|
|
|
|
From these small motor power value experiments we realised a flaw in our program, namely that we had forgotten to stop the light sensor motor after trying to reposition the sensor at the original spot, which ment that it just kept going to the left until a new light registration was initiated by the follow behavior.
|
|
|
|
|
|
|
|
With these flaws in our algorithm now corrected we where able to see the actual effect of the parameters. We therefore observed the robot with a motor power of 60 and a delay before stopping at 100 ms. This turned out to be a much to small angle with the result that the difference between the left and right measured light values was not large enought whereby the driving motors were simply set to move forward, rather than following the light properly. We therefore tried increasing the delay to 300 ms. This didn't seem to make much of a difference, so we increased it to 500 ms, which was the initial value. The reason for us concluding that this might be a solution was, that we had realized that the initial observations couldn't be trusted due to the algorithmic flaws. This seemed to work better as seen in video 7.
|
|
|
|
|
|
|
|
This didn't seem to make much of a difference, so we increased it up to 500 (the intial value). This seemed to work better as seen in video 7, but the robot was turning away from the light rather than towards it. This was due to an error in our code - we simply flipped left and right turns in the code.
|
|
|
|
With this flaw in our algorithm corrected we where able to see the actual effect of the parameters. We therefore observed the robot with a motor power of 60 and a delay before stopping at 100 ms. This turned out to be a much to small angle with the result that the difference between the left and right measured light values was not large enought whereby the driving motors were simply set to move forward, rather than following the light properly. We therefore tried increasing the delay to 300 ms. This didn't seem to make much of a difference, so we increased it to 500 ms, which was the initial value. The reason for us concluding that this might be a solution was, that we had realized that the initial observations couldn't be trusted due to the algorithmic flaws. This seemed to work better as seen in video 7. The video shows that the light sensor was now turning at a satisfying speed until a big enough angle, but ends up reporting the opporsite behavior to the driving motors, as the robot drives right, when the light source is left of the robot and vice versa. This issue was quickly solved by simply inverting the directions of the light sensor motor in all used places.
|
|
|
|
|
|
|
|
[](https://www.youtube.com/watch?v=63BJjsBgtrg)
|
|
|
|
*Video 7: Motorized LightSensor working well with the proper variables.*
|
| ... | ... | |
