In this lab session we will make a Sumo Wrestler.
Duration of activity: 7 hours
Group members participating: Ole Rasmussen, Kasper Sørensen
 |
| Figure 1 - Sump Wrestler Baby. Lets see if we can take him out.... |
Goal
To build a Sumo Wrestling robot and win the competition. Also, learning some behavior driven robot programming.
Plan
We will execute the following in sequence:
- Create the base sumo wrestling robot from building instructions
- Compile, test and observe default behavior driving wrestling controller program
- Examine the source code to determine how it works
- Explain questions about the source code
- Add OverturnOpponent behavior
1. Create base Sumo Wrestling robot
In this step we will construct the base sumo wrestling robot. We will build it from the instructions given here. There were no problems constructing the robot. The base robot as constructed can be seen in Figure 2.
There is not much more to say to this section. Lets move on and add some behavior to the robot.
 |
| Figure 2 - The constructed base sumo wrestling robot. |
2. Sumo Wrestling controller program
In this section we will install a pre-programmed controller program onto the robot. Dependencies for the program is given here. Having installed the robot we took a test run at the wrestling area. We observed that the robot only drove forward for very little time and then stopped to change direction. We adjusted the threshold value inside the AvoidEdge behavior from 45 to 50.
Testing the robot again, we observe that the robot manages to stay inside the wrestling ring, stopping when approaching the edge. If not at the edge, the robot randomly drives forward and turns. Our robot was able to push another standard robot out of the arena - Hurrah!
3. Examine source code
Here we will examine which behaviors exists on how they work.
Examining the source code shows three different behaviors. They each have the ability to disable the behavior listed before it. They are listed below.
- Drive behavior
- Turn behavior
- AvoidEdge behavior
Lets see how they are each triggered:
3.1 Drive behavior
The drive behavior is not triggered by anything, it simply drives forward, and then yields, letting other Threads be scheduled.
3.2 Turn behavior
The turn behavior is triggered every five seconds. It then stops the car, waits for it to stop, and turns it for some milliseconds in the interval [500, 1500].
3.2 AvoidEdge behavior
The AvoidEgde behavior is highest priority behavior. It has the ability to supersede all the other behaviors. It is triggered by a the LightSensor registering a light value above a given threshold.
The behavior is then to drive backwards for one second, turning left for 800msec and then stopping and staying there for 500msec.
3.3 Sum up
The given behaviors will make the robot drive around randomly, but avoiding the edge. The code is nicely structured and it should be easy to extend with new behaviors.
4. Explain questions about the source code
In the lab lesson, three questions are asked. We will try to answer them here.
4.1 Why are threads running in Daemon mode?
The behavior class extends from the Thread class. The constructor inside the Behavior class sets the thread to run in Daemon mode. The question is here, why?
The JDK Javadoc has a good explanation of what a Daemon thread is:
"Marks this thread as either a daemon thread or a user thread. The Java Virtual Machine exits when the only threads running are all daemon threads.
So if only Damon threads exists in a given Java Runtime, the Runtime will exit. This is used in the SumoBot class, so that when pressing the Exit button, the Main method will return and thereby the only thread running in non-daemon mode has halted, making the program exit.This method must be invoked before the thread is started."
Had the Behavior threads not been marked as Daemon threads, the program would continue to execute.
4.2 How is the SuppressNode used to suppress access to the motors in the Behavior class?
The suppression mechanism used is a hierarchy where a behavior on level is able to suppress any behavior on levels below it. This hierarchy can be seen in Figure 3.
All behaviors have access to the sensors, but only one behavior have access to the actuators at a given time. Level 1 is able to suppress Level 0, and so on up the levels.
 |
| Figure 3 - Layered behaviors |
When constructing a behavior using the Behavior class, one can supply a behavior which it is able to suppress. This can be used to create a hierarchy as just described. When a behavior at level N calls the suppress method on the Behavior object, the SupressNode's suppress method is called. This method will increment a counter for the Behavior at level N-1 and call the supress method on that SuppressNode which, in turn, will increment a counter at level N-2 and so on until the bottom is reached. This will make sure that a behavior at Level [0, N-1] have a SuppressNode with a counter value larger than 0.
When a behavior wants to control the actuators, the behavior will first check if the SuppressNode given for it has a counter value at zero, if not, nothing happens.
4.3 Compare the suppression mechanism with Fred Martins' Arbiter
Fred Martins' Arbiter is a central component which registers which behaviors wants to have access to an actuator. The behaviors have a priority, and the behavior with the highest priority will have sole access to the actuator. This acomplishes the exact same thing.
5. Add OverturnOpponent behavior
This section is about adding a behavior to flip over our opponent. We did not believe in the construction of the forlift arm in the hinted building instructions. Lifting heavy robots is not an easy thing.
We wanted to build our own system. Figure 4 shows our construction with our forklift system.
 |
| Figure 4 - Custom built forklift system |
The behavior triggers every four seconds, lifting the forklift, waiting a bit, then taking it down again. See below for a run against another robot in the arena:
