|
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.
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 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.
|
