... | ... | @@ -88,7 +88,7 @@ The robot was rebuilt to include two light sensors instead of the sound sensor, |
|
|
![robot with light sensors](https://gitlab.au.dk/LEGO/lego-kode/raw/master/week8/img/firefry1.PNG)
|
|
|
*Figure 3: Robot fitted with two light sensors*
|
|
|
|
|
|
We created a program, ***LightLover.java***, which behaves similarly to ***SoundLover.java*** - the difference being that we now have two sensors, mapping one sensor's light readings to the power of one motor, and the other sensor's readings to the power of the other motor. We created Braitenberg's Vehicle 2a (see Figure 4) by simply mapping the value measured by the left sensor to the left motor, and the value from the right sensor to the right motor. As we have programmed for an exitatory behavior, this means that high light levels on the left sensor will induce a high power on the left motor and as a result cause the robot to drive *away* from light sources. The resulting behaviour turned our to be that the robot mostly stood still, as the ambient light values in the room did not map to a high enough motor power to get the motors to actually move (the measured values would lie around 57). However, when stimulated by a bright light source, such as the torch on our phone, the robot accurately drives away from it, as shown in Video 8. If we wanted the robot to properly drive around and watch out for light, we could simply do a small calibration by adding some extra base power to each motor, to get the robot to actually drive around in ambient lighting
|
|
|
We created a program, ***LightLover.java***, which behaves similarly to ***SoundLover.java*** - the difference being that we now have two sensors, mapping one sensor's light readings to the power of one motor, and the other sensor's readings to the power of the other motor. We created Braitenberg's Vehicle 2a (see Figure 4) by simply mapping the value measured by the left sensor to the left motor, and the value from the right sensor to the right motor. As we have programmed for an exitatory behavior, this means that high light levels on the left sensor will induce a high power on the left motor and as a result cause the robot to drive *away* from light sources. The resulting behaviour turned our to be that the robot mostly stood still, as the ambient light values in the room did not map to a high enough motor power to get the motors to actually move (the measured values and resulting motopower would lie around 57). However, when stimulated by a bright light source, such as the torch on our phone, the robot accurately drives away from it, as shown in Video 8. If we wanted the robot to properly drive around and watch out for light, we could simply do a small calibration by adding some extra base power to each motor, to get the robot to actually drive around in ambient lighting
|
|
|
|
|
|
[TODO: Light hater vidz]
|
|
|
*Video 8: The robot moving away from bright light*
|
... | ... | @@ -103,7 +103,7 @@ Next, we constructed vehicle 2b by simply switching the attachments of the conne |
|
|
|
|
|
We did not create similar programs with inhibitory connections, but they would be reasonably trivial. It could be obtained simply by inverting the values used as parameters for the motor powers. This would cause the robot to stand still when measuring bright light and drive towards dark (low light) sources.
|
|
|
|
|
|
TODO: Formulér: Behavior of several robots with candle on the ass in a dark room
|
|
|
We proceeded on to having several robots running ***LightLover.java*** move about in a dark room wearing lights. Our observations from this are summarized in Table 1.
|
|
|
|
|
|
| Situation | Explanation |
|
|
|
| ------------- | ----------- |
|
... | ... | @@ -111,12 +111,13 @@ TODO: Formulér: Behavior of several robots with candle on the ass in a dark roo |
|
|
| 2a Inhibitory | The robots stop when getting close to another robot and start again when the other drives away. The end result is the robots following each other |
|
|
|
| 2b Exitatory | Same behavior as 2a Inhibitory (TODO: Pending godlike Camilla forklaring) |
|
|
|
| 2b Inhibitory | Same behavior as 2a Exitatory |
|
|
|
*Table 1: Observations of several light-bearing robots running the LightLover program*
|
|
|
|
|
|
In our experiments so far we have included the entire range of raw light values from 0 to 1023 in our mapping calculations. This has not been a massive problem given the light environment we were in, but could be improved by adapting our calculations to include the maximum and minimum light values sensed during execution of our programs, and using these values as the mapping range in our calculations, similar to Tom Deans suggests in [2].
|
|
|
In our experiments so far we have included the entire range of raw light values from 0 to 1023 in our mapping calculations. This has not been a massive problem given the light environment we were in, but could be improved by adapting our calculations to include the maximum and minimum light values sensed during execution of our programs in this specific environment, and using these values as the mapping range in our calculations, similar to what Tom Dean suggests in [2].
|
|
|
|
|
|
We have not implemented adaptive minimum and maximum light values in our program, but a simple way to do this would be to maintain a list, or rather a queue, of the last *N* light readings from our sensors, where we throw the oldest value out when the queue is full, and then every update we take the maximum and minimum values from this queue to use for our calculations.
|
|
|
We have not implemented adaptive minimum and maximum light values in our program, but a simple way to do this would be to maintain a FIFO queue of the last *N* light readings. For every update we would then take the maximum and minimum values from this queue to use in our calculations.
|
|
|
|
|
|
To experiment with the improvements of this adaptation, we would try to set the robot in an environment where we could freely control the ambient lighting to a strong degree, for example completely darken the room and then light it up again. By having the 2b exitatory the robot drive in a normal lighting environment and having it drive around, suddenly turning off all the lights should cause the robot to stop dead, as the new ambient lighting is far too low to give much power to the engines. However, after enough time has passed for all the recorded light values in the queue to be shoved out, the robot would adapt to the new low ambient lighting, and start driving around normally again, searching light sources.
|
|
|
A way to experiment with this adaptation to investigate the improvements introduced by it could be to place the robot in an environment where the ambient lighting could be controlled to a high degree, for example with the ability to completely darken the room and then light it up again. By having the 2b in the exitatory mode, having the robot drive around in a medium lit environment and suddenly turning off all the lights should cause the robot to stop dead, as the new ambient lighting is far too low to set the power level of the motors high enough. However, after enough time has passed for all the recorded light values in the queue to be shoved out, the robot would adapt to the new dim ambient lighting and start driving around normally again, searching for sources of light.
|
|
|
|
|
|
While we have no video to see the behavior of the robot described in figure 6, we can assume that it would crash into any small object placed directly in front of it, as the sensors are placed far too wide to detect any hindrance like this. A solution to this problem would be to simply place the sensors much closer to the center of the robot. There is no need for them to be further away than the edge of the robot, in order to prevent it from bumping into anything.
|
|
|
|
... | ... | |