Date: 18th of April 2013
Participating group members: Kenneth Baagøe, Morten D. Bech and Thomas Winding
Activity duration: 6 hours

Goal
The goal of this lab session is to construct a robot for the Lego Sumo Wrestling contest as described in the lesson plan.

Plan
The plan is first follow the instruction in the lesson plan and then improve the robot to increase our chances of winning the contest.

Progress
Construction and first observations
We started out by constructing the robot as described in the lesson plan, pictured below.

Next, we installed the basic program on the robot and tried running it in the arena. Below is a short video of it, showing the behaviour of the robot when running in the arena without an opponent, can also be viewed here: http://youtu.be/7NbRPb7FulY.

From observing the robot running the program we saw what we expected to be two triggers: When the robot saw the white edge on the arena and every five seconds, these can also be seen in the video above.

The behaviour of the robot wheen seeing the white edge is that it backs up a bit and then turns, where both the backwards distance moved and the angle turned are constant. The behaviour related to the trigger that happens every five seconds is that it turns, this time the angle of the turn is random. Finally when none of the two mentioned triggers were triggered the robot would simply move forward at full speed.

The SumoBot code
Looking into the code we found that the structure of the lower and higher levels of control can be depicted as seen in the figure below.

This means that the drive function is the lowest priority of the behaviours of the robot, whenever a trigger is triggered the drive behaviour will be suspended. The second-lowest behaviour is the turn behaviour which turns the robot in place, this behaviour can be suspended only by the edge avoiding behaviour. Finally the highest priority behaviour of the robot is avoiding the edge, being the highest priority means that it can never be suspended and will always take precendece over any other behaviour.

Taking an example from the code, the turn behaviour is implemented with the following code.

As can be seen our assumption that the turn behaviour happened roughly every five seconds was correct as there is a delay of 5000ms. When the turn behaviour starts actually doing something, that is, when the delay has been completed, it starts by suppressing the behaviour that has priority right below it. This is then followed by the functions that makes the robot turn a random angle. Finally the behaviour releases the suppression on the behaviour that it suppressed when it started.

This basic idea of “suppress behaviour below in regards to priority – execute behaviour – release suppression” is used in all the behaviours in the SumoBot and should make it fairly straightforward to add extra behaviours to the robot.

The way that each behaviour knows what to suppress is implemented in the abstract class Behavior.java where the constructor asks for a behaviour. This provided behaviour is then treated as the one right below in a subsumption architecture. If one should be interested in creating a new lowest priority behaviour, it should be noted that the lowest priority behaviour is simply provided null as its subsumed behaviour.
When a behaviour receives a subsumed behaviour it creates a SuppressNode which, in its essence, contains a counter for the number of times it has been suppressed. When a behaviour suppresses another behaviour the suppress cascades down the subsumption architecture, basically incrementing the suppress counter for every lower priority behaviour by one, and vice versa for the release function.

The function of the SuppressNode is then to tell whether or not a behaviour is suppressed which is determined by the simple function of whether the suppress counter is zero or not.

OverturnOpponent/Improving the SumoBot
After finishing construction of the base SumoBot we started adding the functionality for overturning an opponent in the arena, we went about this by adding a supersonic distance sensor to the robot to determine whether there is something in front of it and adding a forklift arm to do the overturning.

Our first attempt was following the extension guide for the base car to add the forklift arm and the supersonic sensor to build a robot that looked like the picture below.

This way of constructing the robot, however, presented a number of problems: The forklift arm was not very rigid, owing to the fact that it was only secured in one side. The forklift arm could also not be lowered all the way to a horizontal position because it would hit the light sensor. Finally the supersonic sensor could not always be used to detect whether there was something in front of it since it was mounted to point straight ahead. Testing against the base car which is not very tall we found that the sensor would not pick up the opponent at all.

The above things taken into consideration we rebuilt the extensions somewhat to remedy the problems. This meant that we moved the forklift arm forward a bit so it would not hit the light sensor, secured the arm on the other side of the robot to stabilize it and tilted the supersonic sensor downwards so it could pick up objects in front of it that were short.

This construction worked well as all the problems described above were resolved: The arm could now lower all the way to a horizontal position, it wasn’t as wobbly and the supersonic sensor could be used to detect smaller robots in front of it.

A final problem was that the even though the forklift was now pretty rigid and more sturdy than the first build, the motor that controlled it was not strong enough to actually lift an opponent robot. We tried to remedy this by gearing the forklift motor up but that still did not output enough power to lift another robot. We also noted found that the distance sensor was angled too much downwards to properly detect opponents, therefore we angled it just a bit more up which made the detections of opponents more reliable.

The Forklift behaviour
As we added a new functionality to the robot when we added the forklift arm, we had to add a new behaviour. This behaviour would utilize the forklift arm to try to overturn the opponent when the robot detected the opponent by way of the supersonic sensor.

The behaviour was implemented in Forklift.java, the main part of the behaviour is pictured below (where uss is the supersonic sensor and motor is the motor that controls the forklift arm).

The behaviour checks the distance until it finds something less than 15 cms away from the robot, when this happens the robot suppresses the lower prioritized behaviours, raises the forklift arm and moves forward at full speed for two seconds and then lowers the arm again, followed by releasing the suppression.

When programming this behaviour we did not implement a functionality to suppress the access to the motor that moves the forklift arm as we knew that only a single behaviour would be accessing it. This is important to keep in mind should we ever want to expand upon this program since it would create problems if we tried to access the motor from multiple behaviours.

We added the forklift behaviour as the second-highest priority for the robot (SumoBot.java), leaving the avoid-edge behaviour as the highest priority. This gave us the levels of control depicted in the figure below.

As we were adding the forklift behaviour we also wrote another behaviour that could possibly be used in lieu of the forklift. This behaviour (Ultrasonic.java) would simply move the robot forward at full speed when something was detected in front of the robot.

Conclusion
As noted above, even when gearing up the motor that controls the forklift arm it did not output enough power to actually lift another robot. We don’t know whether it’s possible to add further strength to the arm, but it seems to be necessity to actually be able to overturn opponents. Otherwise a different approach to the SumoBot could be the “move-forward-when-opponent-detected” behaviour that was described above. This approach would simply attempt to push the opponent out of the arena instead of flipping him over.