Date:
4/11 2010
Duration of activity:
3 hours
Group members participating:
Frederik, Christian & Lasse
Goals:
The overall goal for this lab exercise is to analyse and experiment with a provided subsumption architecture
Plan:
1. Observe behaviour with only RandomDrive active.
2. Observe behaviour with RandomDrive and AvoidFront active
3. Observe behaviour with all 3 classes active.
4. Integrate "Drive towards light" behaviour (from ex. 7).
2. Observe behaviour with RandomDrive and AvoidFront active
3. Observe behaviour with all 3 classes active.
4. Integrate "Drive towards light" behaviour (from ex. 7).
Results:
Figure 1 - Car with ultra sonic sensor mounted
1.
The vehicle had only one behaviour; driving randomly around, not caring if there were any obstacles. The display shows the characters 'f' and 's' when driving forwards and stopped respectively.
2.
Behaviour:
The vehicle now shows an extra external behaviour; avoiding obstacles in front. Inspection of the code behind shows that the threshold for deciding when to begin avoidance is 20 cm.
Besides this the vehicle still drives randomly around.
Display:
General:
Display shows a '1' when it is being suppressed, and 'b', 'f', and 's' when vehicle is driving backwards, forwards or is stopped respectively.
AvoidFront:
Shows distance to obstacle - value of 255 is max/none obstacles detected.
3.
Besides the behavoiur from pt. 2 the vehicle now displays the additional behaviour of emitting a mating* sound every 10 sec. This is the highest prioritized behaviour in the vehicle, and it will suppress the other behaviours when active.
The display shows '1' next to each component when this is suppressed; AvoidFront and RandomDrive show '1' when PlaySound is active, and RandomDrive shows '1' when AvoidFront is active.
The hierarchy for the three components are shown below.
*The reasoning for assuming this is a mating sound is that this behaviour has the highest priority in the hierarchy, and thereby suppresses any other behaviour.
4.
The vehicle was retrofitted with RCX lightsensors as seen on Figure 3, and the "Drive towards light" behaviour was attempted to be integrated into the vehicle.
A modified version of the class used for this behaviour was recycled from exercise 7. Unfortunately it was not a perfect modification, as the overall behaviour of the robot degraded as seen in the video below.
It was, however, still possible to observe the suppress mechanism, when the PlaySounds-component was prioritized over TowardsLight[1]; when PlaySounds was active, the TowardsLight was suppressed. An illustration of the hierarchy is shown on Figure 4 below
The vehicle had only one behaviour; driving randomly around, not caring if there were any obstacles. The display shows the characters 'f' and 's' when driving forwards and stopped respectively.
2.
Behaviour:
The vehicle now shows an extra external behaviour; avoiding obstacles in front. Inspection of the code behind shows that the threshold for deciding when to begin avoidance is 20 cm.
Besides this the vehicle still drives randomly around.
Display:
General:
Display shows a '1' when it is being suppressed, and 'b', 'f', and 's' when vehicle is driving backwards, forwards or is stopped respectively.
AvoidFront:
Shows distance to obstacle - value of 255 is max/none obstacles detected.
3.
Besides the behavoiur from pt. 2 the vehicle now displays the additional behaviour of emitting a mating* sound every 10 sec. This is the highest prioritized behaviour in the vehicle, and it will suppress the other behaviours when active.
The display shows '1' next to each component when this is suppressed; AvoidFront and RandomDrive show '1' when PlaySound is active, and RandomDrive shows '1' when AvoidFront is active.
The hierarchy for the three components are shown below.
Figure 2 - The three original behaviours shown as a subsumption architecture
*The reasoning for assuming this is a mating sound is that this behaviour has the highest priority in the hierarchy, and thereby suppresses any other behaviour.
4.
The vehicle was retrofitted with RCX lightsensors as seen on Figure 3, and the "Drive towards light" behaviour was attempted to be integrated into the vehicle.
Figure 3 - Car with two RCX light sensors and an ultrasonic sensor
A modified version of the class used for this behaviour was recycled from exercise 7. Unfortunately it was not a perfect modification, as the overall behaviour of the robot degraded as seen in the video below.
It was, however, still possible to observe the suppress mechanism, when the PlaySounds-component was prioritized over TowardsLight[1]; when PlaySounds was active, the TowardsLight was suppressed. An illustration of the hierarchy is shown on Figure 4 below
Figure 4 - The updated architedture with the TowardsLight behaviour as second priority
Conclusion:
The Thread.setDaemon(true) allows us to treat the thread as a daemon ie. no need to manually handle thread termination since daemon threads automatically will shut down whn other threads are terminated.
The suppressCount integer used for suppresion in the Behavior class is used like a semaphore - incrementing on suppress() and decrementing on released(). This is useful when multiple behaviors are active and uses supress() to supress lower prioritized behaviors. In this case the lowest prioritized behaviors supressCount will be incremented to the amount of higher prioritized behavior that has supressed it. Therefor the lowest prioritized behavior will be suppressed until all higher prioritized behaviors has released the suppression.
The problems with integrating the TowardsLight behavior was caused by the fact that the original design of that class was not made with subsumption architecture in mind. Hence the degraded overall functionality of the behavior. To fix this we would probably need to implement the behavior from scratch.
Overall a good exercise in how to implement several prioritized behaviors in an architectural easy and manageable way.
References:
[1] TowardsLight implementation - http://dl.dropbox.com/u/2389829/Lego/Lab8/TowardsLight.java