Lab 7

Date: 29.03.2012

Duration: 3 hours

Group members: Stefan, Thomas and Jeppe

Goal

LEGO car that exhibits several behaviors

Build the 9797 Lego car as described on page 28 to 30 in the NXT booklet.

Observe the car and try to identify
1) the different behaviors observed and
2) the circumstances that triggers the different behaviors.

Behaviors as concurrent threads
3) Look into the three classes RandomDrive, AvoidFront and PlaySound and try to identify how the triggering condition is implemented and
4) how the actions for each behavior is implemented.

5) Try to watch the car with only RandomDriver and
6) then with only the two first threads active to observe the behaviors more clearly.

Class Behavior

7) What is the purpose of making these threads daemon threads as done in the constructor of the Behavior class? - To make sure that all threads are killed when the main thread is killed.

8) How is the "suppressCount" integer in the Behavior.java class used to implement a suppression mechanism to obtain controlled access to the motors.
9) Compare this with the arbiter of Fred Martin.

Add a behavior "Drive toward light"
10) Try to implement the "Drive toward light" of Lesson 6 as a behavior thread and include it in the subsumption mechanism of SundCar.java. This include to
11) figur out under what conditions the behavior should be triggered and the priority of the behavior in the subsumption architecture.

Plan

Build the robot as described on page 28 - 30 in the NXT booklet.
Then start solving the tasks outlined in section Goal. We divided the tasks between:
Jeppe solves 3-7, Thomas solves 8 - 9, Stefan solves 10 - 11 and 1 - 2.

Results

1) The robot seems to execute its commands a bit sequential, however the hierarchy does work.

First it moves a bit random, then it plays a sound. Avoid front obviously has a higher priority than the move random.

2) Circumstances that triggers different behaviors:
Sound is triggered every 10 second, avoid front is triggered when an obstacle is encountered.

The random movement is active when the two above is not.

3-4) Implementation of the triggering mechanism.

The tree classes RandomDrive, PlaySound and AvoidFront all extends the Behavior class.

The first thing that happens in each of the three classes run method is that they call suppress. This method will suppress all the other behaviors lower in the hierarchy than the current. If one of the threads is already suppressed, it will still start executing its commands. The thread is not blocked. This could easily be a problem. We will elaborate further on this problem in (8).

5) With only RandomDrive, the robot moves slowly around and does not avoid any objects
6) Without RandomDrive the robot does not move unless an object is placed in front of it. It will still play the sounds every 10 second.

7. What is the purpose of making these threads daemon threads as done in the constructor of the Behavior class?

A daemon thread is automatically terminated when all non daemon threads have finished their executions. The purpose of making the threads in the behavior class daemon is that when someone presses the Escape button on the NXT, the “Main”-thread finishes execution and all behavior threads automatically closes down. If this was not the case the robot would continue running its program – in effect becoming stuck running the program.

8. How is the "suppressCount" integer in the Behavior.java class used to implement a suppression mechanism to obtain controlled access to the motors?

When a higher priority behavior executes it’s suppress method all lower priority behaviors have their suppressCount integer increased by 1 recursivly. Whenever a behavior tries to send a command to the motors using methods forward, backward and stop it is only actually executed whenever the behavior’s suppressCount is 0. This way it is ensured that only the highest priority behavior wanting to access the motors actually accesses the motors. Whenever a behavior calls its release method all lower priority behaviors have their suppressCount decreased by 1 recursivly. This may allow a lower priority behavior to execute its motor control commands.    

The pattern has a problem in that it allows a subset of a behavior’s sequence of motor commands to be executed instead of all of them. For instance in the SoundCar example the robot may be very close to a wall when the play sounds behavior is activated. While the robot is break dancing the avoid wall behavior keeps executing its instructions and again and again and may resume control of the motors after it has executed the following instructions:

backward(70,70);

drawString("b");

delay(1000);

And just before it executes:

forward(0,80);

drawString("f");

delay(800);

Resulting in the robot maybe driving into the obstacle!

11) figur out under what conditions the behavior should be triggered and the priority of the behavior in the subsumption architecture.
In the original LightSensorCar, the loop would run every 250 ms, to get a new reading from the light sensor, and then set the power accordingly.


This was changed, so the loop would run, when the sensors detected a light source above a certain threshold. This would make the car try to drive towards a light source, if one that is powerful enough is detected.


Then the priority of the light method would be set to just above the random walk. This way the robot would play sounds, and avoid walls, and turn randomly, as long as no source of bright light was detected. When a source of bright light was detected however, the car would begin to turn towards this, while still trying to avoid bumping into walls, and still playing sounds.

9. Compare this with the arbiter of Fred Martin:

The arbiter pattern is a centralized way of archiving the same as the subsumption pattern. In the arbiter pattern a class is created that runs through all threads / objects wanting to use the motors and executes the class’ instructions with the highest priority. The subsumption pattern archives the same in a decentralized way using recursive calls. 

Conclusion

We tried working with a behavior hierarchy and observed the robot. The suppression hierarchy does work, but yields a potential issue if the robot suppresses a lower hierarchy action in the middle of its command sequence. 

This started a good discussion in the group.
Consider that I am holding a cup of hot coffee in my hand. Then my primary task is to keep the coffee in the cup. If I then want to see what time it is on my wrist watch, then I might end up poring out the coffee when I turn my arm.
So a hierarchy of suppression always comes with some cost on the lower ranking processes.

I.e. they might be suppressed in the middle of a sequence of commands.

References

Lab 7, http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson7.dir/Lesson.html