NXT Programming
Lesson 10
In this lab session we will investigate how a
behavior-based architecture, [1],
has been implemented in the subsumption API of leJOS NXJ. Especially, we will
investigate the interface lejos.subsumption.Behavior and the class
lejos.subsumption.Arbitrator and try to make an alternative implementation of
the Arbitrator.
BumperCar
As an example of a behavior-based control program the leJOS NXJ
distribution contains a BumperCar program in the folder samples/BumperCar.
It consists of two behaviors DriveForward and DetectWall
both implementing the interface Behavior and a main program
BumperCar that uses an instance of the class Arbitrator
to control the
activation of the two behaviors. First, make BumperCar run on an NXT.
Then make the following experiments with the BumperCar to investigate
the functions of the Arbitrator:
-
Press the touch sensor and keep it pressed. What happends ? Explain.
-
Both DriveForward and DetectWall have a method takeControl that are called
in the Arbitrator. Investigate the source code for the Arbitrator
and figure out if takeControl of DriveForward is
called when the triggering condition of DetectWall is true.
-
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.
-
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 continous sampling.
-
Try to implement the behavior DetectWall so the actions taken also involve
to move backwards for 1 sec before turning.
-
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.
Motivation Functions
When the DetectWall behavior is active another hit on
the touch sensor will not reactivate the action sequence in the method
action. It makes of cause no sense to reactivate action as long as
touch is pressed but what if it is pressed again while it is turning ?
Lets consider how Thiemo Krink's motivation functions, [2], can be used to
make such a reaktivation possible. Describe how takeControl could return a
motivation value. e.g. an integer value. The behavior with the highest value is then
activated each time through the loop in the Arbitrator.
How could takeControl be programmed to give high values
when touch is pressed and lower values when it is ok to reactivate the action
method ?
References
Last update: 15-11-09