Testing a sumoBot

Robot-sumo, or pepe-sumo is a sport in which two robots attempt to push each other out of a circle/ring (in a similar fashion to the sport of sumo). The robots used in this competition are called sumoBots.

The challenges for the sumoBot are:

• to find the opponent (accomplished with IR [infrared], Ultrasound, Presence sensors)
• to push it out of the flat arena
• to avoid leaving the arena (usually by means of a sensor that detects the edge, e.g BW [Black & White] sensors)

Standard class sumoBots:

• may average up to 3 kg
• must fit inside a 20 cm by 20 cm box
• can have any height

To make this easier, we’ll take as a reference point the robot V.A.S.I.L.E.

V.A.S.I.L.E [Very Advanced Intelligent Sumo Lifeless Entity]

…is a sumoBot sponsored by Altom, which participated to the National Robo Challenge competition at Bucharest, the 15th of May, 2010.

The team had about a month until the competition to design, get the necessary components and build the sumoBot. Getting the components was the biggest issue. First of all, we couldn’t have in time the motors we needed (suitable for sumo robot competitions). Some of the motors that we found didn’t meet the requirements (they were too big, more than 20 cm by 20 cm) and ordering suitable ones from online sites would have taken too long. After one of our colleagues searched his basement, we were lucky he found an old printer with some pretty good motors, which also provided us the wheels. But another problem was encountered: the need of gear-box. We only knew one person who could provide us the gear-box, but we were told it would take a week to finish it. Even though the rest of the components were sent fast, the whole motors and gear-box process took about three weeks to arrive. Finally, we had only six days left until the competition for the actual building of the sumoBot.

The team was initially formed by three members: Andrei Cociuba, Lucian Nertan and me. This kind of competition was a novelty for us. I previously built a similar bot at a course in Ankara, “Robotic Days” organized by BEST, but it was much more simplistic than now. Andrei is very experienced in advanced circuitry and all team members had good programming skills, excelling with Lucian. A day before the competition, Dan Salagean, software tester, gave us a hand in software debugging and bug fixing. Together, we made use of our skills the best we could.

With little time to finish the sumoBot, we tried to work quickly and efficiently. Even if V.A.S.I.L.E was not planned to use a certain model, during the process we used elements of trial and error and scrum methods, that we knew from software development. V.A.S.I.L.E grew up based on daily scrum meetings, when we quickly discussed an overall about our project:

• what we did the day before
• what we’re doing today and who’s doing what
• issues preventing to accomplish our goals, solutions

It was particularly useful, to have a formal and focused way to communicate, especially that we were running out of time and needed to be efficient.

If I were to describe the phases of building the robot, I would mention five important moments:

1. Planning, when we analyzed the competition requirements and specifications, sketched the sumoBot design and got the components.
2. After planning, the compatibility testing was done. The motors, gear boxes, wheels and battery were mounted on the chassis. The target was to determine V.A.S.I.L.E to move, without additional circuitry.
3. BW (Black White) sensor circuits and trigger circuits for the BW sensors were done and tested.
4. All sensors were mounted on V.A.S.I.L.E and tested using software test programs. Also, additional components were mounted on the robot, i.e little protection wheels for BW circuits, wheels protection, attack and defense blades.
5. Writing and testing the software. The software was based mostly on trial and error methods, e.g: Motor directions were set by writing ad hoc software with motor directives. The software was uploaded on V.A.S.I.L.E’s microprocessor. V.A.S.I.L.E was put in the sumo ring and observed. After identifying the motor directions (forward, backward, left, right), the software was improved and corresponding procedures were created (GoForward(int), GoBackward(int), GoLeft(int), GoRight(int)).

Of course we also encountered lots of issues:

• The trigger circuit: We applied three different methods to build it (one of them based on operational amplifiers, another one resistance-based and the last one using a NAND circuit. Unfortunately, neither of them worked as indented. The trigger circuit was supposed to launch an interruption when any of the BW sensors would detect the white border).
  Solution: Technical debt, i.e none of the trigger circuits wasn’t used anymore, the BW sensors being wired directly to the mainboard. This debt affected us later, creating problems with the delay, which is described in detail later on.
• Burnt motor drivers. During one of our hardware tests, while supplying the motors circuit, the motor driver got burnt.
  Solution: We bought one for the circuit and another one for future burn-downs, but our work was slowed down two days because of this. During those two days, we tried to work on other independent components of the sumoBot, e.g, Analytic sensors.
• V.A.S.I.L.E was overweight (more than 3 Kilos).
  Solution 1: We drilled holes in the chassis to lose weight, a process we laugh at referring to as “the liposuction process”. The method proved to be inefficient because we needed way too much weight to be dropped.
  Solution 2: We bought a new battery, which weighted 0.5 Kilos less than the current one.
• Find opponent strategy was inefficient. After some tests we realized the positioning the sensors is not very helpful to find the opponent bot. The initial configuration was with 1 * US plus 1 * Presence sensors in front and 1 * IR back. This changed to 2 * IR plus 1 * Presence sensors in front and 1 * US back. With two analog sensors in the front and some computations, we could search for the opponent only once during a round and detect its moving direction. This way, V.A.S.I.L.E could move synchronously with the opponent.
  Solution: Designed and constructed new blades with shells for the sensors. This lasted about 4 hours. We also rewrote the software program in order to match the new logic.

One day left until the competition…
We had one day left to write the final software and test it. We also had to consider to successfully pass the preliminary task: to push a box out of the ring. During our scrum meeting that day, we decided there wasn’t enough time to write advanced defense procedures, so we focused on finding the opponent and attacking it. With the two advantages listed above (weight and motors), V.A.S.I.L.E could handle the situation.

Testing V.A.S.I.L.E

We had to cover two aspects: the hardware and the integrated/embedded software. We started with tests for the hardware. If I were to label the types of testing we did, that would be:

1. Functional testing

BW sensor read: After soldering the circuits for BW sensors, we tested them with corresponding equipment consisting of power supply and oscilloscope.

Detecting opponent sensor read: Infrared, Ultrasound, Presence sensors. We tried to identify sensor’s behavior taking into account the possible noise (object presence near the ring – the Ultrasound is detecting objects on 6 meter distance) and calibrate the sensors according the output values.

2. Integration testing

We tested V.A.S.I.L.E under normal conditions.

On a regular collision with the opponent

• The components don’t fall off the chassis
  We checked the motors and gear-box (they were mounted under the chassis), the battery (which was not glued on the chassis), the mainboard (was very sensitive on wire connections. At this part we also found a bug: V.A.S.I.L.E had problems with directions as the motor driver was not fixed very well on its socket and the pin connection was sometimes lost).
• BW sensors
  We made sure motors don’t smoke, BW sensors don’t scratch the floor (as they were mounted very close to the floor. To prevent this, we used some little wheels near the BW sensors, to have a smooth movement)

When being pushed out of the ring, we assured that

• The sumoBot can be easily be stopped even when executing the procedures
• The components don’t fall off the chassis
• The mainboard circuits don’t break
• The BW circuits don’t break

3. Load testing

We loaded an object that V.A.S.I.L.E had to push. We stopped at 5 Kilos.

Then, we continued with tests for the software:

• Direction directives: Go Forward, Go Back, Go Right, Go Left
• Turn directives: Turn 90 degrees, Turn 180 degrees. Turn 180 degrees procedure was very useful when the US sensor mounted at V.A.S.I.L.E’s back would detect the opponent
• Avoid leaving the ring.

When the opponent is not detected yet

We implemented a ring coverage with the help of the BW sensor read procedures combined with motor directives procedures, in order to stay in the ring.

When the opponent is detected
Our strategy was to give priority to BW sensor read before executing other procedures. Then,

• Find opponent: developed a procedure to cover the whole ring in only a few moves
• Attack opponent: the attack is done by simply going forward toward the opponent to get it out of the ring.

We also thought of other strategies like, first going back and then go forward to gain speed or attack from one of the right or left sides of the other sumoBot, in order to be more difficult to get attacked. These ideas remained in our minds for future competitions, as now we needed to focus on what we could develop and test in the time we had. It was hard to keep ourselves away from implementing cooler strategies, but we got tempered by our experience working as testers, knowing that untested code is a direct highway to failure. So we kept it simple and testable.

Hardware-Software dependency
The hardware-software dependency was one of V.A.S.I.L.E’s weak points. The issue was that we relied on how charged the battery was to execute the direction and turn procedures correctly. For example, if the US sensor detected the opponent, the following code would be executed:

/*
Variables and parameters:
us –> the ultrasound sensor which is mounted at the back of the sumoBot
long, short -> delay Constants

Procedures:
GoLeft(int delayConstant)
GoForward(int delayConstant)
These direction procedures go left / forward for a certain amount of ms (milliseconds), specified by the delayConstant

The logic:
When the us (ultrasound) sensor detects the opponent, turns 180 degrees and then attacks it(by going forward)
*/

if (us < 30){
GoLeft(long); //turn 180 degrees
GoForward(short); //attack
return;
}

The 180 degree turning is done by going left a certain amount of time, specified by the parameter long. The issue here was that the variable long depends on how charged the battery was. If the battery is charged 100% it takes a certain amount of time to turn 180 degrees and if the battery is charged only 50%, the time to turn 180 degrees increases.

Issue because of inefficient testing
Another delay issue was that when the delay function was called, the software froze. We discovered this problem only during the competition, when V.A.S.I.L.E got out of the ring by itself, and the local press commented:“V.A.S.I.L.E was shy”.
This can be exemplified in the following code sample:

/*
Going left is mechanically done by turning the left wheel backwards and the right wheel forward.
*/

void GoLeft(int delayConst = 0)
{
MotorLeftBack(); //left motor spins back
MotorRightForward(); //right motor spins forward
delay(delayConst); //going left for a certain amount of time, expressed in ms
}

If the delayConstant is 1000 ms (1 second), then during that second the sensors are not read. This means that if in less than one second V.A.S.I.L.E gets at the white border, it cannot detect it. Taking into account the delay constant can also take higher values and that the sumoBot is almost in continuous movement , the chance to miss the white border is very high.

The competition
A month before the national competition, another local competition had been organized in Bucharest. This local event helped the teams which won a lot, as it gave them time to improve and test their sumoBots. Consequently, the competition level was very high and the robots were very good. Having the honor to compete with such sumoBots taught us a lot of things and gave us a lot of hints to improve our own sumoBot.

From design point of view, V.A.S.I.L.E should have had an angle blade in front. The angle blade is the most common “weapon” used in a sumobot competition, usually tilted about 45 degrees towards the back of the sumoBot. The angle blade is far better than the normal blade V.A.S.I.L.E had, because it goes with the idea of going under the opponent in order to determine it to lose adherence. This way, it is much easier to push the opponent out of the ring.

Another design aspect which could have been improved is the height of V.A.S.I.L.E. Even if the specifications of robot-sumo regarding height is unlimited, the principle of sumoBots is ”the lower, the better”.

Regarding hardware, some time should be spared for failover. There always should be a PLAN B if the components burn or crash, the battery discharges, the sumoBot doesn’t fit the requirements, something happens during a fight etc.

We have also noticed that it is allowed to have more microprocessors with different software that can be switched during the competition. This idea goes with applying different strategies considering equivalence classes of sumoBots’ characteristics.

Another lesson learned is to try to eliminate the hardware-software dependency which was previously discussed.

…see you soon
From this experience we have learned a lot of things to improve our working technique on sumoBots.

V.A.S.I.L.E will be soon improved and will compete in Cluj-Napoca in December at “BattleLab ROBOTICA” competition. It will be a first-time for Cluj-Napoca in this field and we hope it’s going to be a success.

The competition will be organized by the Technical University Electrical Engineering Faculty, having as main coordinator PhD. Eng. Septimiu Crisan. This event is an extraordinary chance to prove what we’ve learned from this experience and also for other students to gather their skills and build strong sumoBots to challenge V.A.S.I.L.E II.

External links:
Robo Challenge Competition
Robot-Sumo [Wikipedia]