@@ -83,30 +83,32 @@ Initially we basically copied earlier mentioned pseudocode (without the flags).
The final implementation of our Escape behavior can be found in .
### Motor for light sensor
We rebuilt our robot and put the lightsensor on a motor, so it wouldn't have to turn its entire body when looking around. The result is shown in figure 5. We then changed the car movement to a new motor. We used too much power though! This resulted in a wicked case of robotic autoerotic asphyxiation as seen in video 6. This happened due to a delay of 500 ms. We then changed that to a 100 ms.
After implementing the additional behavoir for our behavoir control, we were asked to mount the robots light sensor on an additional motor as seen on the lesson plan picture. This installation would then enable the follow behavior to check for better light source without turning the actual robot. To do this we started out by rebuilding the robot. The new look can be seen in figure 5, where the light sensor is now attached to a third motor.
*Figure 5: Rebuilt robot mounting the LightSensor on a motor*
The follow behavior implementation now needed an update to use the new motor atachment. Initially we simply replaced all calls to car.forward or car.backwards with the coresponding calls to the new motor and thereby using the same motorpower values and milisecond delays. This however resulted in a very dramatic reaction where the robot nearly strangled itself in the attached vires as seen in video 6 where a motorpower of 70 and a milisecond delay of 500 ms were used.
After observing the dramatic turn of the light sensor, we realised that the turn-angle was simply too big and concluded that due to less resistance on the extra motor compared to the two initial motors, there was two ways of effecting this; by changing the motor power or the delay. We decided on changing the delay from the initial 500 ms to 100 ms, as the speed of the rotating light sensor seemed about right. This didn't work as expected as the angle still seemed wrong.
We realized that a GUI would have been a good idea, to ease testing of different parameters.
At this point in time, we realized that a GUI for transmitting motor power - and delay parameters while running the program would have eased the testing of best fitting parameter values. We however judged that the time invested in implementing such a GUI and fitting it with the existing programs would take longer time than simply trying different values. So, we switched off all other behaviors to ease the observation of the follow behavior and started testing different combinations of motor power - and delay values, by starting with varying the motor power, starting with relatively small values.
The reason for lowering power and interval time: less resistance on motor so less force needed.
| Motor power | Observation |
| --- | --- |
| 30 | No movement, but loud noise from motor |
| 45 | Still no movement |
| 55 | Movement, but too small angle |
| 60 | Movement, seems ok, but turns in opposite direction of light and keeps moving after last check |
Switched off all other behaviors to be able to test it.
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.
70 went crazy (as seen in video 6)
Change length of interval from 500 to 100.
Try: 30 - hyletone, no movement
Try: 45 - still nothing
Try: 55 - better, but not responsive enough
Try: 60 - seems to work ok, but keeps turning left (as it keeps going even when it's not longer registering light. We tried to stop the motors after making the sensor point forward again)
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.
Stopping the motors in the end helped. But it seemed that the sensor wasn't turning enough when checking, so that the difference between the left and right light values was not large enough, whereby the motors were simply set to move forward, rather than following the light properly. We tried increasing the interval to 300. 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.
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.