NXT Programming

Lesson 9, sumo wrestling robots

In this lab session we will construct and program a sumo wrestling LEGO robot and at the end of the lab session the sumo wrestling LEGO robots will fight against each other in a sumo arena as described in Figure 1.

Figure 1 Two LEGO robots are ready to start a wrestling fight.
The fight ends when the loosing robot is pushed out of the arena
or is overturned. If this does not happend in 2 minutes the fight
ends as a draw.
The sumo wrestling robots driving base should be based on the ideas in Express bot, a fotobased building instructions for a base car with extensions. A simple LEGO sumo wrestler can e.g. be build as follows (click on the image to see details):
The sumo robot should be programmed by means of the behavior-based control paradigme, [2].

Before we program the sumo robot 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.


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 the base sumo wrestler driving base mounted with a bumper and an ultrasonic sensor.

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.
  • 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 ?
  • 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.
  • The takeControl method of DetectWall contains a call to the ultrasonic sensor method getDistance that includes a delay. This means that the call of takeControl for the other behaviors is delayed and the reaction to an event is not immidiate. In [1] it is recommende that takeControl "should return quickly, not perform a long calculation." To avoid the pause in the takeControl method of DetectWall a local thread in DetectWall could be implemented that sample the ultrasonic sensor e.g. 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 or 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.

First change the interface Behavior so takeControl returns a motivation value. e.g. an integer value. The behavior with the highest motivation value should then be activated each time through the loop in the Arbitrator.

Second, implement a new Arbitrator that does this.

Third, change the BumberCar behaviors DriveForward, DetectWall and Exit so takeControl returns motivation values. Especially, 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 ?

In Behavior.java, Arbitrator.java and BumperCar.java there are files that show how it can be done.

A Behavior-based Control Program for the Sumo Wrestler Robot

Use the behavior-based control paradigme, [2], to program the sumo wrestling robot. As a basis for the implementation use either the leJOS behavior-based architecture, [1], or use the classes with the modifications described above.

The rules for a sumo robot is as follows:

  • The sumo wrestling robots driving base should be based on the ideas in Express bot, a fotobased building instructions for a base car with extensions.
  • Only LEGO elements can be used in a LEGO sumo robot.
  • The weight of a sumo robot must be less that 1 kilo. The floor extension should be within 30 cm x 30 cm.
  • A sumo robot has to be autonomous.
  • After a press on a start button the sumo robot should wait 3 seconds before it begins.


Last update: 23-4-15