Notebook 10


Lab Notebook

Date: 02/02 2012
Group members participating: Falk, Jeppe and Jakob
Duration of activity: 3 hours


Ivestigate how a behavior-based architecture can be implemented and look at lejos.subsumption.Behavior and lejos.subsumption.Arbitrator.


  • Build a robot and add a sonic- and a touch-sensor.
  • Make the BumperCar program run on the NXT.
  • Investigate the behavior of the BumperCar program.
  • Implement a behavior called BumperCar program.
  • Investigate the source code of the Arbitrator.
  • Implement a solution that reads the ultrasonic sensor continuously.
  • Implement HitWall so it moves backwards for 1 second before turning.
  • Implement HitWall so it can be interrupted.
  • Change the program so it uses motivational values.


The robot

The robot was build accordingly to the manual 9797 page 8-22. Ultrasonic sensor added according to page 28-29, and the touch sensor is added according to page 36.

Behavior of

When the touch sensor is pushed once, it just cotinues going forward. If the touch sensor is pressed for longer time the robot backs off and turns a little to the left. For the ultrasonic sensor the behavior is the same when it detects an obstacle.
When the isPressed action is true it's start going backwards (HitWall), but as soon as it's false it continues normal operations (DriveForward).

Implementing the Exit behavior

When pressing the escape button shortly while the robot is executing DriveForward, the robots stops momentarily and then continue to drive forward. When the escape buttons is hold for a duration during DriveForward the program exits. Pressing the escape button, for any duration, while the robot is executing the HitWall results in the program exiting .
It could be because the Exit behavior doesn't execute System.exit(0) before the control is handed back to the (DriveForward). And exits right away when it's executing the Hitwall because the ultrasonic sensor takes ~ 20 msec to measure distance and therefore the Hitwall takes back control after 20 msec, which means that Exit has time to execute System.exit(0).

We solved this with a variable called pressed, that is set to true when Exit gets control, and control is not given back as long as pressed is true. Thereby simulating holding the escape button.

    public boolean takeControl() {
        if (button.isPressed()) {
            pressed = true;
        return pressed;

Investigating the Arbitrator

We tested if the Arbitrator calls takeControl in the different beahaviors, by making a counter and printing how many times takeControl is called. It seems that the lejos Arbitrator doesn't call takeControl. It's because once the Arbitrator reaches a true value from takeControl on a behavior, starting from the max priority, there is no reason for it to continue and it executes the given behavior.

Continuously read of the ultrasonic sensor

This is achieved by running a local tread inside the HitWall behavior, which update the distance value every 20 msec.

        public SonicThread(SensorPort port) {
             sonar = new UltrasonicSensor(port);
        public void run() {
            while (true) {
                HitWall.distance = sonar.getDistance();
                LCD.drawString("distance: " + distance + "  ", 0, 4);

Implementing changes in HitWall

Making the robot go backwards for 1 second before turning is achieved with Thread.sleep(1000). We didn't manage to make the HitWall interrupt itself, so we moved on to "implementing" motivational values.

Change the program so it uses motivational values

The classes provided in the lesson (Arbitrator, Behavior and BumperCar) is used to achieve this, because of shortage of time.
The provided code works as expected, and the Hitwall/DetectWall is able to interrupt itself by using the motivational values.


Behavior based design is an easy way to program a robot with different behaviors, and it proved easy to add a new behavior with a higher priority.

As seen in the lab-session there can be issues regarding a behavior loosing control before it's done executing all it's operations, and it seems that the behavior based design of lejos have some shortcomings where there is some to gain by using motivational values instead.


Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License