Date: 1. maj 2014
Duration of activity: 10.00 - 15.15
Group members participating: Christian Hansen, Pætur Askildsen, Søren Gregersen
Goal: To build a LEGO Sumo wrestler that can beat out the other robots in the wrestling arena.
Plan:
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.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):
Figure 1: Two LEGO robots are ready to start a wrestling fight. The fight ends when the losing robot is pushed out of the arena or is overturned. If this does not happen in 2 minutes the fight ends as a draw.
The sumo robot should be programmed by means of the behavior-based control paradigm, [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 interfacelejos.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 happens?
When the touch sensor is kept pressed, the method action in the detectWall class is continuously repeated. This means that the car drives backwards for a short moment and thereafter turns slightly left. In the code this is:
BumperCar.leftMotor.rotate(-180, true);
BumperCar.rightMotor.rotate(-360);
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?
When DriveForward is active, the Exit behavior is called instantly when the Escape button is pressed. So at any time, we are able to interrupt the program by pressing the Escape button. But when DetectWall is active, the Exit behavior cannot be activated by pressing the escape button when the program is in the middle of a loop. It is only possible to interrupt the DetectWall with the Exit behavior when the escape button is pressed immediately after the cycle described in the previous exercise has finished, that is just after the right motor has stopped rotating. This is because the BumperCar.rightMotor.rotate(-360); is a blocking method. It can be replaced by BumperCar.rightMotor.rotate(-360, true) to make the method return 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.
takeControl of DriveForward is not called when the triggering condition of DetectWall is true since DetectWall has a higher priority than DriveForward. This can be seen in the Monitor thread in figure 2, where it runs through the behavior[] ArrayList from the largest index/priority and downwards, and if takeControl of a behavior at a index returns true, that behavior is set as the highestPriority and the for-loop breaks. So if a higher-priority behavior’s takeControl method returns true, a lower priority behavior’s takeControl method is not called.
Figure 2: Excerpt from the Monitor thread. This shows that takeControl of DriveForward is not called when the triggering condition of DetectWall is true, since DetectWall has a higher priority than DriveForward.
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 recommended 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 continuous sampling.
We tried to continously sample the UltraSonic sensor readings in a local thread, making the DetectWall behavior as follows in figure 3, where a while(true) loop runs continuously updating the sonarDistance variable almost as often as possible with a sleep delay of 5 ms. We chose the 5 ms because the sonar.getDistance already takes some while to find a distance:
public int getDistance()
Return distance to an object. To ensure that the data returned is valid this method may have to wait a short while for the distance data to become available.
so that hopefully we will get a sample approximately every 20 msec, but we don’t know what the exact time the of the getDistance method to return is. We could have made tests to find the average time the getDistance method takes to return a distance to be able to specify a more correct sampleTime, but we choose to be satisfied with a guess because of time considerations.
Figure 3: The DetectWall behavior now samples the sonarDistance in a local thread to make DetectWall’s takeControl return as immediate as possible.
Try to implement the behavior DetectWall so the actions taken also involve to move backwards for 1 sec before turning.
We did this by adding a few lines of code to the DetectWall action() method:
Figure 4: The DetectWall behavior actions now go backwards for 1 sec before turning.
But this made the car not go straight backwards when the DetectWall action() was called immediately as it first rotated a little counterclock-wise. We think this is because the BumperCar sample code uses RegulatedMotors instead of MotorPort motor controls, and therefore it runs a little while backwards with only the leftMotor.backward() command active before rightMotor.backward() is started, cf. Figure 4.
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.
This behaviour was not implemented, but we had a good talk about the reason for implementing this behavior. If the surroundings are static and the manoeuvre for avoiding the object only consist of a backwards driving and a turn, it does not make sense to take care of another push on the button.
But if the surroundings are not static (e.g. robots driving around on a track) or the avoidance manoeuvre also consists of a forward driving with the risk of bumping into objects or other robots while performing the action, it would make sense to implement it.
One thing to always be aware of though is that if this behavior is not implemented, the robot is “deaf” and “blind” to it’s surroundings while performing the avoidance manoeuvres.
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 course 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 reactivation 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 ?
We did not have time to code this ourselves, but we have investigated the classes Behavior.java, Arbitrator.java and BumperCar.java to see how it may be done.
A Behavior-based Control Program for the Sumo Wrestler Robot
Use the behavior-based control paradigm, [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.
We used a defensive strategy: Our Sumo Wrestler Robot just turned the footlights of the light sensors on and just stood still, hoping that the other wrestler would drive off the track.
We fought against two opponents which we could keep up with, meaning we had 1 point in both matches. Our car stood rock solid even though the other cars used all their power to push our car off the track. After one minute the opponent realized that our car was not going to move at all, and they wanted to call a tie to save battery for their next race.
We used this defensive strategy because, in the time available, we could not get our intended behaviours to work. We wanted to implement three behaviours, inserted in a Behavior arraylist as follows:
- Stand still (standard)
- Attack (if bumper is pressed)
- Avoid (if light sensor detect white)
If the sensors did not detect anything, the car should just stand still.
We equipped the car with two light sensors, one in the front and one in the back. If the front light sensor detected white, the car would drive backwards and if the rear light sensor detected white, the car would drive forward.
In the front of the car we mounted two bump sensors, which were connected to a ramp which should work in the same way as a snowplow does: it would reject the opponents attempt to throw our robot of the arena but also try to push the other robots out of the arena.
Conclusion:
We got 2 points in the preliminary sumo wrestling robot round (2 ties), and we are satisfied with that result.
References:
[2], Jones, Flynn, and Seiger, "Mobile Robots, Inspiration to Implementation", Second Edition, 1999.
[3], Thiemo Krink(in prep.). Motivation Networks - A Biological Model for Autonomous Agent Control.
Ingen kommentarer:
Send en kommentar