NXT Programming - Lesson 10

---

Date: 22.11.2007
Duration of activity: 4 hours
List of participants: Alessandro, Daniela, Samuele

---

Goal: Identifying the advantages of a motivation based behaviour in an agent

Plan:

1. rebuild robot
2. get used with the subsumption API of leJOS NXJ
3. test the sample program
4. test with bump sensor pressed
5. add PlaySound

We rebuilt the robot following the classical model described on the Lego^© handbook to add the bump sensor.



The Behavior interface was simple to understand, but we spent more time to analyze the code of Arbitrator. After having realized how it is supposed to work, we uploaded the code and tested it.

On a trivial test, it showed no undesired effect, but when testing, as suggested, with the bump sensor pressed, it stops. This is because, how the Behavior tutorial says, "it executes the action() method of that behavior once and only once".
Since the array of Behaviors is visited from right to the left, and the visit is interrupted whenever a behavior wants to take control, takeControl methods of lower priority Behavior are not called any more.

Before trying to fix that unwanted behavior, we adapted the PlaySound to implement the Behavior interface, and added it as an high priority behavior, as usual.
That was pretty easy, and worked as usual. It didn't happen that a lower priority behavior is still active when it is suppressed, but we tried to figure out when it could happen:
If the BehaviorAction thread is paused (by the JVM or explicitly) before the Behavior action() method ends, while inside the Arbitrator thread a Behavior with higher priority (PlaySound, in this case) triggers, it can cause some problems.
In this case, the suppress method of the Behavior is called while the action method execution is paused, possibly inside a Thread.sleep() instruction, so it wouldn't stop the action execution from this point to the end. Then the higher level action execution is queued, and will be called when the action method terminates. But in this case, the suppress() method wouldn't be called.
In this case, this issue cannot easily affect the overall Behavior of the robot, since the action method of the HitWall behavior ends with two motor.stop(), but in general it can often cause unexpected behaviors, for instance if the higher priority behavior accesses the motors.

New plan:

1. Implement the suggested arbitrator strategy
2. Analyze possible problems of the implementation
3. Try the motivation strategy

We changed all behaviors, removing the suppression methods and using a Thread strategy: this time Arbitrator interrupts the executing thread to suppress the associate behavior. Because the suppress method is no more used by Arbitrator we put its signature out from the Behavior interface. We created another interface (MotivationBehavior.java) and adapt all the classes for the motivation behavior architecture: for example, this is the resulting PlaySounds.java.

We didn't have time to try a different strategy where the motivation value is based on dynamic factors like the alive time of a behavior.