NXT Programming lesson 10

Lesson 10 description

Date: 18. November 2010

Duration of activity: 12 - 17

Group members participating: Nikki & Knud

---

GOALS for lesson 10:

Our goal is to explore the lejos behavior based architecture and try to improve it so a simple version of Thiemo Krink’s “Motivation Network” [Krink] can be implemented.

Plan for achieving the goals:

We will explore the lejos behaviour based architecture by following the lesson 10 lab description. We will try to improve the architecture as suggested in lesson 10.

Results:

Results from suggested experiments in lesson 10 lab description:

• “Press the touch sensor and keep it pressed”

When this is done the robot just keeps doing the action of detectwall behavior because takecontrol of detect wall keeps being true and has the highest priority. That action is:

public void action()
{
Motor.A.rotate(-180, true);// start Motor.A rotating backward
Motor.C.rotate(-360);  // rotate C farther to make the turn
}

• “Investigate the source code for the Arbitrator and figure out if takeControl of DriveForward is called when the triggering condition of DetectWall is true.”

takeControl of Drive Forward is not called by the Arbitrator, as DetectWall has higher priority. The Arbitrator calls the behaviours takeControl method in the highest priority order. When a takeControl method returns true, the Arbitrator stops calling further down the list of behaviours.

• “Implement a third behavior, Exit. This behavior should react to the ESCAPE button and call System.Exit(0) if ESCAPE is pressed. Exit should be the highest priority behavior. Try to press ESCAPE both when DriveForward is active and when DetectWall is active. Is the Exit behavior activated immediately ? What if the parameter to Sound.pause(20) is changed to 2000 ? Explain.”

While DetectWall is active, pressing the escape button doesn't exit the program because of no implemented suppress method in DetectWall. Furthermore the takeControl of DetectWall has a delay of 20ms because the ultrasonic sensor being in ping mode so it has to have time for receive the echo. This delay will also contribute to the Escape button press not being detected. To solve these two problems, we removed the delay (and made the sonar ping continuously in the background) and implemented the suppress method in DetectWall (we made sure there was no blocking calls in the action method, ie. the rotate function of Motor.C was blocking).

• “To avoid the pause in the takeControl method of DetectWall a local thread in DetectWall could be implemented that sample the ultrasonic sensor every 20 msec and stores the result in a variable distance accessible to takeControl. Try that. For some behaviors the triggering condition depends on sensors sampled with a constant sample interval. E.g. a behavior that remembers sensor readings e.g. to sum a running average. Therefore, it might be a good idea to have a local thread to do the continuous sampling.”

Avoiding the pause was fixed as described above by making the the ultrasonic sensor continuous. Essentially this runs the sampling in another thread, so no blocking occurs in the takeControl method.

• Try to implement the behavior DetectWall so the actions taken also involve to move backwards for 1 sec before turning.

We implemented the behavior and made sure it could be suppressed.

• Try to implement the behavior DetectWall so it can be interrupted and started again e.g. if the touch sensor is pressed again while turning.

The Arbitrator will not repeat the same behavior, because its priority is the same. We discussed this and came up with 3 solutions:

1. Change the Arbitrator, so the same behaviour (same priority) can be suppressed and restarted.

Pros: Only a small change in the Arbitrator code is necessary.

Cons: We change how the architecture behave, this may affect other behaviours, not expecting to be suppressed by itself.

2. Add the same behavior twice.

Pros: A small change in the main class.
Cons: It can only be interrupted once, unless it is added more than twice

3. Divide the behavior the robot has to make, up in two behaviors. One behavior that backs up the robot and one behavior with 1 priority lower that turns the robot.

Pros: We don't change the architecture and it is not limited to one interruption.
Cons: Backing up the robot behavior have to call the turn behavior.

We considered these solutions, and were in favour of solution c.

Motivation Network:

As suggested in the lab description we could return a float from 0 to 1 or an int from 0 to 1000 from takeControl, where the highest value is the highest motivation. How this motivation value should be calculated is different from each takeControl. In our case the arbitrator would function as the decision-maker, it should call all takeControl methods of the behaviour list, and run the behaviour with the highest motivation factor. To resolve conflicts of two behaviors having the same motivation factor, the priority that they are already listed in should determine which one is the most motivated.

Compared to Fig.1 the mapping functions and motivation variables would equal the takeControl method in the behaviour class. Behaviour patterns would equal the action method in the behaviour class. Decision-maker would equal the arbitrator.
We have not considered internal states and artificial genes.

Fig. 1 - Motivation network [Krink]

Conclusion:

In the lejos behaviour based architecture, it is important that the takeControl method is completed fairly quick, otherwise events may be missed. It is equally important that the action method can be suppressed without delay.
It is possible and fairly easy to implement a simple version of Motivation Networks by modifying the lejos behaviour based architecture.

References:

Krink:
Thiemo Krink (in prep.), Motivation Networks - A Biological Model for Autonomous Agent Control
(http://legolab.daimi.au.dk/DigitalControl.dir/Krink.pdf)