... | @@ -92,19 +92,21 @@ We then tried increasing the values of the threshold for turning left or right t |
... | @@ -92,19 +92,21 @@ We then tried increasing the values of the threshold for turning left or right t |
|
|
|
|
|
The robot was rebuilt to include two light sensors instead of the sound sensor, as shown in Figure 3.
|
|
The robot was rebuilt to include two light sensors instead of the sound sensor, as shown in Figure 3.
|
|
|
|
|
|
![robot with light sensors](https://gitlab.au.dk/LEGO/lego-kode/raw/master/week8/img/firefry1.PNG)
|
|
![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*
|
|
*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 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
|
|
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]
|
|
[![Light haters gonna hate](http://img.youtube.com/vi/R5ao7_WGzs8/0.jpg)](https://www.youtube.com/watch?v=R5ao7_WGzs8)
|
|
|
|
|
|
*Video 8: The robot moving away from bright light*
|
|
*Video 8: The robot moving away from bright light*
|
|
|
|
|
|
Next, we constructed vehicle 2b by simply switching the attachments of the connecting wires of the sensor's (the difference is illustrated in Figure 4, taken from the lesson plan), such that which sensor causes which motor to drive is flipped - i.e. the robot will drive towards light instead of away from it. This is shown in Video 9.
|
|
Next, we constructed vehicle 2b by simply switching the attachments of the connecting wires of the sensor's (the difference is illustrated in Figure 4, taken from the lesson plan), such that which sensor causes which motor to drive is flipped - i.e. the robot will drive towards light instead of away from it. This is shown in Video 9.
|
|
|
|
|
|
![vehicles 2a and 2b](https://gitlab.au.dk/LEGO/lego-kode/raw/master/week8/img/2a2b.PNG)
|
|
![Vehicles 2a and 2b](https://gitlab.au.dk/LEGO/lego-kode/raw/master/week8/img/2a2b.PNG)
|
|
*Figure 4: Illustration of vehicle 2a and vehicle 2b*
|
|
*Figure 4: Illustration of vehicle 2a and vehicle 2b*
|
|
|
|
|
|
|
|
TODO: !!!Nicolai: Der er ingen video i drive til den her D: D: D: D:!!! (Hvis vi ikke har en mener jeg heller ikke det er super vigtigt, ville bare lige forklare hvorfor jeg ikke har sat én ind :P)
|
|
[TODO: LIGHT LOOOVE / Light luvver vid]
|
|
[TODO: LIGHT LOOOVE / Light luvver vid]
|
|
*Video 9: The robot driving towards bright light*
|
|
*Video 9: The robot driving towards bright light*
|
|
|
|
|
... | @@ -143,7 +145,9 @@ The illustration in Figure 6 ("Figure 7" in the lesson plan) shows the sound sen |
... | @@ -143,7 +145,9 @@ The illustration in Figure 6 ("Figure 7" in the lesson plan) shows the sound sen |
|
|
|
|
|
We wrote a program, ***RaveBot.java***, that seeks towards places with both high sound levels and high light levels. The program mostly consists of a mash of our previous programs ***SoundLover.java*** and ***LightLover.java***, where we simply add together the two values received from the sensors and then divide by two (halving the impact of each sensor), using the resulting value as the motor power for the corresponding motor according to the drawing in Figure 6. The result can be seen in Video 10.
|
|
We wrote a program, ***RaveBot.java***, that seeks towards places with both high sound levels and high light levels. The program mostly consists of a mash of our previous programs ***SoundLover.java*** and ***LightLover.java***, where we simply add together the two values received from the sensors and then divide by two (halving the impact of each sensor), using the resulting value as the motor power for the corresponding motor according to the drawing in Figure 6. The result can be seen in Video 10.
|
|
|
|
|
|
[TODO: RAVE BOT TIME WUBWUBWUBWUBWUB]
|
|
|
|
|
|
[![RaveBot: Activate](http://img.youtube.com/vi/8bv9QNYc14I/0.jpg)](https://www.youtube.com/watch?v=8bv9QNYc14I)
|
|
|
|
|
|
*Video 10: Robot running the RaveBot program*
|
|
*Video 10: Robot running the RaveBot program*
|
|
|
|
|
|
The video shows the robot correctly powering up the appropriate motor to seek towards light when registering it. However, the robot most often stops when registering sound, with a slight veering towards the sound source. This is expected, as our inhibitory implementation of the sound sensor causes it to give a great deal of power to both sensors when there is no sound present. If one e.g whistles near one sound sensor, the opposite sound sensor is bound to pick up a great deal of sound as well (although not as much), resulting in lower motor power for both motors. All in all, the combination of sensors works reasonably well, but it could be argued that it would be possible to find a more refined way of calculating the combination of sensor readings, rather than the pretty naive "average of the two" approach that we have used.
|
|
The video shows the robot correctly powering up the appropriate motor to seek towards light when registering it. However, the robot most often stops when registering sound, with a slight veering towards the sound source. This is expected, as our inhibitory implementation of the sound sensor causes it to give a great deal of power to both sensors when there is no sound present. If one e.g whistles near one sound sensor, the opposite sound sensor is bound to pick up a great deal of sound as well (although not as much), resulting in lower motor power for both motors. All in all, the combination of sensors works reasonably well, but it could be argued that it would be possible to find a more refined way of calculating the combination of sensor readings, rather than the pretty naive "average of the two" approach that we have used.
|
... | | ... | |