... | ... | @@ -70,7 +70,7 @@ Next, we modified our program to receive raw values directly from the sensor por |
|
|
|
|
|
[![Raw value SoundLover](http://img.youtube.com/vi/I5IMfdiapT4/0.jpg)](https://www.youtube.com/watch?v=I5IMfdiapT4)
|
|
|
|
|
|
*Video 3: Running SoundLover.java using raw values read directly from the sensor port instead of dB values read from the lejos sound sensor*
|
|
|
*Video 3: Running SoundLover.java using raw values read directly from the sensor port instead of dB values read from the LeJOS sound sensor*
|
|
|
|
|
|
#### Sound Reactor
|
|
|
The next task was to map the raw values to the range [-100, 100], in order for the robot motor power range to go from full power backwards to full power forwards, rather than from full stop to full power forwards. We do this simply by multiplying the percentage of measured raw value (inverted) by 2 - that is, instead of obtaining a percentage value by multiplying by 100, we multiply by the full range value of 200. The resulting value is then added to the minimum range value of -100. We implemented this in the program ***SoundReactor.java*** [5], and the result can be seen in Video 4.
|
... | ... | @@ -89,7 +89,7 @@ We wrote a program, ***SoundHater.java*** [6], as the inhibitory version of ***S |
|
|
*Video 5: The robot running SoundHater.java*
|
|
|
|
|
|
#### Dancing robot
|
|
|
Finally, we made the program ***TinyDancer.java*** [7], where we initially made the robot turn left if the sensor measured a sound level above 50 procent of the totalt spectrum, and turn right if the value was less than 50. The robot kept constantly turning left as the sound level caused by itself was too high. This can be seen in Video 6.
|
|
|
Finally, we made the program ***TinyDancer.java*** [7], where we initially made the robot turn left if the sensor measured a sound level above 50 percent of the total spectrum, and turn right if the value was less than 50. The robot kept constantly turning left as the sound level caused by itself was too high. This can be seen in Video 6.
|
|
|
|
|
|
[![TinyDancer, 1st attempt](http://img.youtube.com/vi/gjiWjaYU4eA/0.jpg)](https://www.youtube.com/watch?v=gjiWjaYU4eA)
|
|
|
|
... | ... | @@ -108,7 +108,7 @@ For this vehicle design the robot was rebuilt again to include two light sensors |
|
|
![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, ***LightHater.java*** [8], 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 motorpower 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, ***LightHater.java*** [8], 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 behavior 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 motorpower 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.
|
|
|
|
|
|
[![Light haters gonna hate](http://img.youtube.com/vi/R5ao7_WGzs8/0.jpg)](https://www.youtube.com/watch?v=R5ao7_WGzs8)
|
|
|
|
... | ... | @@ -123,11 +123,11 @@ 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.
|
|
|
|
|
|
#### Several robots in the dark
|
|
|
We proceeded on to having several robots running ***LightHater.java*** move about in a dark room wearing lights on their rear. As it was not possible to coordinate this with the other groups as we were working friday afternoon and therefore didn't have several other groups in the Suze building, we decided to merely discuss the expected result from a group of robots in a dark room running one of the following four possibilities. The results from this discussion are summarized in Table 1.
|
|
|
We proceeded on to having several robots running ***LightHater.java*** move about in a dark room wearing lights on their rear. As it was not possible to coordinate this with the other groups as we were working Friday afternoon and therefore didn't have several other groups in the Suze building, we decided to merely discuss the expected result from a group of robots in a dark room running one of the following four possibilities. The results from this discussion are summarized in Table 1.
|
|
|
|
|
|
| Situation | Explanation |
|
|
|
| ------------- | ----------- |
|
|
|
| 2a Exitatory | Every time a robot gets close to another robots rear, it sees more light and turns up power at the same side motor resulting in the robots driving away from each other, but slowing down as they get seperated. |
|
|
|
| 2a Exitatory | Every time a robot gets close to another robots rear, it sees more light and turns up power at the same side motor resulting in the robots driving away from each other, but slowing down as they get separated. |
|
|
|
| 2a Inhibitory | The robots stop when getting close to another robot as this gives a high reading of light resulting in less motor power. The robots will however power up their motors when the other robots move away and the sensors sees less light resulting in the robots ultimately following each other.|
|
|
|
| 2b Exitatory | Same behavior as 2a Inhibitory as the robots power up the opposite motor when seeing more light, resulting in them driving toward the light of the other robots rears and thereby following each other.|
|
|
|
| 2b Inhibitory | Same behavior as 2a Exitatory as the robots power up their motors when seeing less light and thereby driving away from the light on the rear of the other robots.|
|
... | ... | @@ -165,7 +165,7 @@ We wrote a program, ***RaveBot.java*** [9], that seeks towards places with both |
|
|
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.
|
|
|
|
|
|
## Conclusion
|
|
|
During this lab we built different versions of the 3 vehicles, that acted upon different kinds of stimuli. We experimented with multiple sensors and different kinds of connections (inhibitory and exitatory). Before testing the different versions, we discussed their expected behaviour, and we were usually correct. We also created two scenarios, where the vehicles had specific purposes - the tiny dancer and the rave bot. This required precise calibration, the correct sensors and fitting connections. Both ended up working well. The lab ended up taking a little longer than expected, but that might have something to do with the two partly missing participants. All in all, the lab was a success and the goal was achieved.
|
|
|
During this lab we built different versions of the 3 vehicles, that acted upon different kinds of stimuli. We experimented with multiple sensors and different kinds of connections (inhibitory and exitatory). Before testing the different versions, we discussed their expected behavior, and we were usually correct. We also created two scenarios, where the vehicles had specific purposes - the tiny dancer and the rave bot. This required precise calibration, the correct sensors and fitting connections. Both ended up working well. The lab ended up taking a little longer than expected, but that might have something to do with the two partly missing participants. All in all, the lab was a success and the goal was achieved.
|
|
|
|
|
|
## References
|
|
|
[1] [Building instructions](http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson6.dir/ExpressBot.pdf)
|
... | ... | @@ -202,6 +202,4 @@ During this lab we built different versions of the 3 vehicles, that acted upon d |
|
|
|
|
|
[17] [Video 8](https://www.youtube.com/watch?v=R5ao7_WGzs8)
|
|
|
|
|
|
[18] [Video 9](https://www.youtube.com/watch?v=8bv9QNYc14I)
|
|
|
|
|
|
[TODO: video refs, they are missing in file-repo, so must be transfered] |
|
|
\ No newline at end of file |
|
|
[18] [Video 9](https://www.youtube.com/watch?v=8bv9QNYc14I) |
|
|
\ No newline at end of file |