... | @@ -8,7 +8,6 @@ |
... | @@ -8,7 +8,6 @@ |
|
In the construction and implementation of vehicle 1: Camilla M. V. Frederiksen, Ida Larsen-Ledet, Nicolai Nibe and Emil Platz
|
|
In the construction and implementation of vehicle 1: Camilla M. V. Frederiksen, Ida Larsen-Ledet, Nicolai Nibe and Emil Platz
|
|
In the construction and implementation of vehicles 2 and 3: Camilla M. V. Frederiksen and Nicolai Nibe
|
|
In the construction and implementation of vehicles 2 and 3: Camilla M. V. Frederiksen and Nicolai Nibe
|
|
|
|
|
|
|
|
|
|
**Activity duration:**
|
|
**Activity duration:**
|
|
6 Hours
|
|
6 Hours
|
|
|
|
|
... | @@ -19,8 +18,7 @@ To build, program and experiment with the Braitenberg vehicles [1], as described |
... | @@ -19,8 +18,7 @@ To build, program and experiment with the Braitenberg vehicles [1], as described |
|
## Plan
|
|
## Plan
|
|
We plan to attempt to complete the exercises within our initially allotted 5 hours.
|
|
We plan to attempt to complete the exercises within our initially allotted 5 hours.
|
|
|
|
|
|
Ida was writing the code, Nicolai took notes, and Camilla and Emil were in charge of performing the experiments. After Ida had to leave, Camilla took over the coding.
|
|
Ida was writing the code, Nicolai took notes, and Camilla and Emil were in charge of performing the experiments. After Ida had to leave, Camilla took over the coding and the two remaining members collaborated on performing the experiments.
|
|
|
|
|
|
|
|
|
|
## Results
|
|
## Results
|
|
We began by rebuilding the robot, looking at the illustrations for the building instructions for *Express-Bot* [1, page 2] as well as the images provided in the lesson plan under *Building Instructions for a Base Vehicle*.
|
|
We began by rebuilding the robot, looking at the illustrations for the building instructions for *Express-Bot* [1, page 2] as well as the images provided in the lesson plan under *Building Instructions for a Base Vehicle*.
|
... | @@ -28,11 +26,10 @@ We began by rebuilding the robot, looking at the illustrations for the building |
... | @@ -28,11 +26,10 @@ We began by rebuilding the robot, looking at the illustrations for the building |
|
![rebuilt robot](https://gitlab.au.dk/LEGO/lego-kode/raw/master/week8/img/firstbot.PNG)
|
|
![rebuilt robot](https://gitlab.au.dk/LEGO/lego-kode/raw/master/week8/img/firstbot.PNG)
|
|
*Figure 1: The robot's new look after rebuild - note the lovely flower; a celebration of spring and robots coming alive*
|
|
*Figure 1: The robot's new look after rebuild - note the lovely flower; a celebration of spring and robots coming alive*
|
|
|
|
|
|
|
|
|
|
### Vehicle 1
|
|
### Vehicle 1
|
|
For the first part of the exercise we wrote a program, **SoundLover.java** [TODO: ref], that made the robot drive with motor power proportional to the sound level measured by a single sound sensor. We could not find specifications on what the sound sensor measures, or what the range of these measurements are, but from our experiments with the sound sensor in Lesson 3 in which the highest value observed was 92, we infer that the readings returned from the sound sensor appear to be dB values somewhere between 0 and 100. Since the interval appears to be [0, 100], we deemed it reasonable to simply map the read sound value directly to motor power and so we pass the measured sound level returned by *readValue()* along as the value for the motor power parameter.
|
|
For the first part of the exercise we wrote a program, **SoundLover.java** [4], that made the robot drive with motor power proportional to the sound level measured by a single sound sensor. We could not find specifications on what the sound sensor measures, or what the range of these measurements are, but from our experiments with the sound sensor in Lesson 3 in which the highest value observed was 92, we infer that the readings returned from the sound sensor appear to be dB values somewhere between 0 and 100. Since the interval appears to be [0, 100], we deemed it reasonable to simply map the read sound value directly to motor power and so we pass the measured sound level returned by *readValue()* along as the value for the motor power parameter.
|
|
|
|
|
|
A range of 0 to 100 could make sense as it incorporates noise levels up to shouting and loud music [3], excluding aeroplane noise and noise above the pain threshold, which seems reasonable for a robot intended for educational purposes. On the other hand, we may simply not have observed higher values as there were no sound sources present to produce noise of that loudness level. This, however, is not important as we will most likely not encounter sound of that level during this session either. And if we do, our past experiences has shown that when values higher than 100 are passed to the robot's motors, they are simply interpreted as a value of 100.
|
|
A range of 0 to 100 could make sense as it incorporates noise levels up to shouting and loud music [3], excluding aeroplane noise and noise above the pain threshold, which seems reasonable for a robot intended for educational purposes. On the other hand, we may simply not have observed higher values as there were no sound sources present to produce noise of that loudness level. This, however, is not important as we will most likely not encounter sound of that level during this session either. If we do, our past experiences has shown that when values higher than 100 are passed to the robot's motors, they are simply interpreted as a value of 100.
|
|
|
|
|
|
Ideally we would run some more thorough experiments to figure out the exact range that the sound sensor can measure, but we opted not to do this. The result of running this program can be seen in Video 1.
|
|
Ideally we would run some more thorough experiments to figure out the exact range that the sound sensor can measure, but we opted not to do this. The result of running this program can be seen in Video 1.
|
|
|
|
|
... | @@ -40,11 +37,12 @@ Ideally we would run some more thorough experiments to figure out the exact rang |
... | @@ -40,11 +37,12 @@ Ideally we would run some more thorough experiments to figure out the exact rang |
|
|
|
|
|
*Video 1: The robot running SoundLover.java*
|
|
*Video 1: The robot running SoundLover.java*
|
|
|
|
|
|
As can be seen in the video, the robot starts driving forward fine when measuring some noise, however it keeps driving forward with full speed despite receiving (almost) no sound. We judged this as being a result of one of two things: The sound sensor could be vibrating too violently when the robot is driving full force, which the sensor interprets as a loud sound thereby causing a constant feedback loop making the robot continue to drive forward. Alternatively, it could simplu be that the sound made by the motors is loud enough to cause the robot to keep driving. A combination of the two being the cause is also likely.
|
|
As can be seen in the video, the robot starts driving forward fine when measuring some noise, however it keeps driving forward with full speed despite receiving (almost) no sound. We judged this as being a result of one of two things: The sound sensor could be vibrating too violently when the robot is driving full force, which the sensor interprets as a loud sound thereby causing a constant feedback loop making the robot continue to drive forward. Alternatively, it could simply be that the sound made by the motors is loud enough to cause the robot to keep driving. A combination of the two being the cause is also likely.
|
|
|
|
|
|
To solve this issue, we rebuilt the robot to extend the sound sensor further away from the robot by placing it on a pole. This could help in both cases: If motor noise was the cause, distancing the sensor from the motors would obviously help. And if vibrations were the cause, placing the sensor on a pole might help as the vibrations on the end of the pole should be of a lower frequency than those produced directly by the robot's motors and movement. The rebuild can be seen in Figure 2 and the result of running the program with this build can be seen in Video 2.
|
|
To solve this issue, we rebuilt the robot to extend the sound sensor further away from the robot by placing it on a pole. This could help in both cases: If motor noise was the cause, distancing the sensor from the motors would obviously help. And if vibrations were the cause, placing the sensor on a pole might help as the vibrations on the end of the pole should be of a lower frequency than those produced directly by the robot's motors and movement. The rebuild can be seen in Figure 2 and the result of running the program with this build can be seen in Video 2.
|
|
|
|
|
|
![re-rebuilt robot](https://gitlab.au.dk/LEGO/lego-kode/raw/master/week8/img/polebot.PNG)
|
|
![re-rebuilt robot](https://gitlab.au.dk/LEGO/lego-kode/raw/master/week8/img/polebot.PNG)
|
|
|
|
|
|
*Figure 2: The robot after second rebuild - notice that the flower is still there*
|
|
*Figure 2: The robot after second rebuild - notice that the flower is still there*
|
|
|
|
|
|
[![Top dollar SoundLover](http://img.youtube.com/vi/EDo4dGzpGTI/0.jpg)](https://www.youtube.com/watch?v=EDo4dGzpGTI)
|
|
[![Top dollar SoundLover](http://img.youtube.com/vi/EDo4dGzpGTI/0.jpg)](https://www.youtube.com/watch?v=EDo4dGzpGTI)
|
... | @@ -53,7 +51,7 @@ To solve this issue, we rebuilt the robot to extend the sound sensor further awa |
... | @@ -53,7 +51,7 @@ To solve this issue, we rebuilt the robot to extend the sound sensor further awa |
|
|
|
|
|
We see that the build solves our problem extremely well, as the robot accurately slows down once we stop making sounds instead of constantly driving at high speed.
|
|
We see that the build solves our problem extremely well, as the robot accurately slows down once we stop making sounds instead of constantly driving at high speed.
|
|
|
|
|
|
Next, we modified our program to receive raw values directly from the sensor port instead of using *readValue()* on the *SoundSensor* class. We did this because we would like an accurately known interval of measured values in order to map to any range that we desire. The sensor measures a raw value between 0 and 1023, where a high raw value means a low sound level. We simply convert the measured value to a percentage of the maximum value 1023, then invert this percentage by subtracting it from 100, and then pass it along as the value of the motor power parameter. As can be seen in Video 3, this modifications still works perfectly fine, and as it allows for more precise and easier mapping to any ranges we want, we decided to continue using raw values.
|
|
Next, we modified our program to receive raw values directly from the sensor port instead of using *readValue()* on the *SoundSensor* class. We did this because we would like an accurately known interval of measured values in order to map to any range that we desire. The sensor port measures a raw value between 0 and 1023, where a high raw value means a low sound level. We simply convert the measured value to a percentage of the maximum value 1023, then invert this percentage by subtracting it from 100, and then pass it along as the value of the motor power parameter (se code snippet 1). As can be seen in Video 3, this modification still works perfectly fine, and as it allows for more precise and easier mapping to any ranges we want, we decided to continue using raw values.
|
|
|
|
|
|
[TODO: Perhaps insert code example?]
|
|
[TODO: Perhaps insert code example?]
|
|
|
|
|
... | @@ -69,13 +67,13 @@ The next task was to map the raw values to the range [-100, 100], in order for t |
... | @@ -69,13 +67,13 @@ The next task was to map the raw values to the range [-100, 100], in order for t |
|
|
|
|
|
After being thoroughly confused by draw int for a while (TODO: Ida forstår ikke det her - det var da ikke DrawInt, der forvirrede os? Nicolai: Jo, det var hvor vi troede den viste 300-600 hvor den kun burder vise værdier fra 0-100, men det var bare fordi vi ikke clearet displayet så det 3. digit stadig var der fra de gange den viste 100), we managed to get it working. As can be seen in the video, the robot drives forward and backward according to sound level reasonably appropriately, although it appears that when driving backwards the noise/vibrations caused by the robot is enough of an increase in the values picked up by the sensor that the robot immediately slows down its backwards driving and even drives forward a bit.
|
|
After being thoroughly confused by draw int for a while (TODO: Ida forstår ikke det her - det var da ikke DrawInt, der forvirrede os? Nicolai: Jo, det var hvor vi troede den viste 300-600 hvor den kun burder vise værdier fra 0-100, men det var bare fordi vi ikke clearet displayet så det 3. digit stadig var der fra de gange den viste 100), we managed to get it working. As can be seen in the video, the robot drives forward and backward according to sound level reasonably appropriately, although it appears that when driving backwards the noise/vibrations caused by the robot is enough of an increase in the values picked up by the sensor that the robot immediately slows down its backwards driving and even drives forward a bit.
|
|
|
|
|
|
We wrote a program, ***SoundHater.java***, as the inhibitory version of ***SoundLover.java***. The program is exactly the same as the SoundLover program, except we don't invert the read value. The result is shown in Video 5. The robot accurately stops when hearing loud noises and drives forward under low sound levels.
|
|
We wrote a program, ***SoundHater.java*** [5], as the inhibitory version of ***SoundLover.java***. The program is exactly the same as the SoundLover program, except we don't invert the read value. The result is shown in Video 5. The robot accurately stops when hearing loud noises and drives forward under low sound levels.
|
|
|
|
|
|
[![SoundHater](http://img.youtube.com/vi/be89rHd9oHs/0.jpg)](https://www.youtube.com/watch?v=be89rHd9oHs)
|
|
[![SoundHater](http://img.youtube.com/vi/be89rHd9oHs/0.jpg)](https://www.youtube.com/watch?v=be89rHd9oHs)
|
|
|
|
|
|
*Video 5: The robot running SoundHater.java*
|
|
*Video 5: The robot running SoundHater.java*
|
|
|
|
|
|
Finally, we made the program ***TinyDancer.java***, where we initially made the robot turn left if the sensor measured a sound level above 50 (TODO Ida: som i 50 procent? Eller dB? Nicolai: Procent... I think? Halp i need 2nd opinion Camilla), 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*** [6], where we initially made the robot turn left if the sensor measured a sound level above 50 (TODO Ida: som i 50 procent? Eller dB? Nicolai: Procent... I think? Halp i need 2nd opinion Camilla), 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)
|
|
[![TinyDancer, 1st attempt](http://img.youtube.com/vi/gjiWjaYU4eA/0.jpg)](https://www.youtube.com/watch?v=gjiWjaYU4eA)
|
|
|
|
|
... | @@ -95,7 +93,7 @@ The robot was rebuilt to include two light sensors instead of the sound sensor, |
... | @@ -95,7 +93,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)
|
|
![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*** [7], 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.
|
|
|
|
|
|
[![Light haters gonna hate](http://img.youtube.com/vi/R5ao7_WGzs8/0.jpg)](https://www.youtube.com/watch?v=R5ao7_WGzs8)
|
|
[![Light haters gonna hate](http://img.youtube.com/vi/R5ao7_WGzs8/0.jpg)](https://www.youtube.com/watch?v=R5ao7_WGzs8)
|
|
|
|
|
... | @@ -131,8 +129,8 @@ A way to experiment with this adaptation to investigate the improvements introdu |
... | @@ -131,8 +129,8 @@ A way to experiment with this adaptation to investigate the improvements introdu |
|
In the lesson plan, an alternative build is presented (see Figure 5, "Figure 6" in the lesson plan). We have no video showing the behavior of the robot shown in Figure 5, but we assume that it would crash into any small object placed directly in front of it, as the sensors are placed with far too large a space in between them to detect a hindrance of this form. A solution to this problem would be to simply place the sensors 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. (TODO: kunne det ikke være, at der er en god grund til, at sensorerne er så langt ude? (Ida))
|
|
In the lesson plan, an alternative build is presented (see Figure 5, "Figure 6" in the lesson plan). We have no video showing the behavior of the robot shown in Figure 5, but we assume that it would crash into any small object placed directly in front of it, as the sensors are placed with far too large a space in between them to detect a hindrance of this form. A solution to this problem would be to simply place the sensors 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. (TODO: kunne det ikke være, at der er en god grund til, at sensorerne er så langt ude? (Ida))
|
|
|
|
|
|
![alternative build](https://gitlab.au.dk/LEGO/lego-kode/raw/master/week8/img/fig6.PNG)
|
|
![alternative build](https://gitlab.au.dk/LEGO/lego-kode/raw/master/week8/img/fig6.PNG)
|
|
*Figure 5: Alternative build, as illustrated in the lesson plan*
|
|
|
|
|
|
|
|
|
|
*Figure 5: Alternative build, as illustrated in the lesson plan*
|
|
|
|
|
|
### Vehicle 3
|
|
### Vehicle 3
|
|
|
|
|
... | @@ -141,10 +139,10 @@ The lesson plan's first suggestion is to use a light sensor and an ultrasound se |
... | @@ -141,10 +139,10 @@ The lesson plan's first suggestion is to use a light sensor and an ultrasound se |
|
The illustration in Figure 6 ("Figure 7" in the lesson plan) shows the sound sensors with a direct, inhibitory connection to the motors, while the light sensors have a 'crossed', exitatory connection to the motors. Based on our experiences in the previous exercises, we can infer from this that the robot will steer towards both light and sound.
|
|
The illustration in Figure 6 ("Figure 7" in the lesson plan) shows the sound sensors with a direct, inhibitory connection to the motors, while the light sensors have a 'crossed', exitatory connection to the motors. Based on our experiences in the previous exercises, we can infer from this that the robot will steer towards both light and sound.
|
|
|
|
|
|
![vehicle 3 diagram](https://gitlab.au.dk/LEGO/lego-kode/raw/master/week8/img/fig7.PNG)
|
|
![vehicle 3 diagram](https://gitlab.au.dk/LEGO/lego-kode/raw/master/week8/img/fig7.PNG)
|
|
*Figure 6: The diagrammatic illustration of Vehicle 3 provided as Figure 7 in the lesson plan*
|
|
|
|
|
|
|
|
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.
|
|
*Figure 6: The diagrammatic illustration of Vehicle 3 provided as Figure 7 in the lesson plan*
|
|
|
|
|
|
|
|
We wrote a program, ***RaveBot.java*** [8], 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.
|
|
|
|
|
|
[![RaveBot: Activate](http://img.youtube.com/vi/8bv9QNYc14I/0.jpg)](https://www.youtube.com/watch?v=8bv9QNYc14I)
|
|
[![RaveBot: Activate](http://img.youtube.com/vi/8bv9QNYc14I/0.jpg)](https://www.youtube.com/watch?v=8bv9QNYc14I)
|
|
|
|
|
... | @@ -162,4 +160,14 @@ TODO |
... | @@ -162,4 +160,14 @@ TODO |
|
|
|
|
|
[3] [The decibel scale with examples, in Danish](http://fys.dk/fipnet/1_oeret/11_temaer/116_skala/)
|
|
[3] [The decibel scale with examples, in Danish](http://fys.dk/fipnet/1_oeret/11_temaer/116_skala/)
|
|
|
|
|
|
[TODO: refs til kode] |
|
[4] [The Soundlover.java program]()
|
|
\ No newline at end of file |
|
|
|
|
|
[5] [The SoundHater.java program]()
|
|
|
|
|
|
|
|
[6] [The TinyDancer.java program]()
|
|
|
|
|
|
|
|
[7] [The LightLover.java program]()
|
|
|
|
|
|
|
|
[8] [The RaveBot.java program]()
|
|
|
|
|
|
|
|
[TODO: video refs] |
|
|
|
\ No newline at end of file |