Proceedings of

RoboCup Challenge @ India 2009

IIT Kharagpur

Editors :

Kaustubh Tripathi
(Department of Computer Science
and Engineering)

Sanjiban Choudhury
(Department of Electrical
Engineering)

1
Foreword
RoboCup Challenge @ India 2009 will be India’s christening in the field of soccer
robotics. With the start of this event, we begin treading on the road to an advanced AI and
robotics platform that very few countries enjoy the luxury of. The efforts of the elite teams in
India, which are published in this journal, are of surprisingly sophisticated nature given this is
the inaugural year of this event.
Over the last few years, even though robotics competitions in the country have been
escalating – both in numbers as well as in difficulty – they are still a step back from matching
the standards of the leading research institutions in the world. With the advent of
RoboCup, the struggle to match the “state of the art” levels has already begun. The soul of
the research is embodied in the development of multi-agent dynamic systems with
coordination and cooperation models.
RoboCupTM (Originally called as Robot World Cup Initiative) is an international
research and education initiative. It is driven by the initiative :

“By mid-21st century, a team of fully

autonomous humanoid robot soccer players
shall win the soccer game, comply with the
official rule of the FIFA, against the winner of
the most recent World Cup.”

To promote the same spirit of research, IIT Kharagpur is hosting a “related event” in
association with the Federation. In the inaugural year, we are adopting two of the standard
events – Small Sized League and Soccer Simulation League.
This year we had the pleasure of reviewing a vista of work with several innovative
aspects. The work not only displayed fantastic implementation of age old algorithms, it also
encompasses several intelligent and inspiring solutions faced by the participants. We were
overwhelmed by how the technical entry barriers into events of such magnitude were
overcome. If we were to compare our start to the beginnings of well established RoboCup
giants around the world, our start with the latest platforms of omni-drives and advanced
strategy is truly remarkable.
This year’s effort has truly set up the platform for really exciting research to grow in
the coming years. Whether it be the usage of more sophisticated motors or of faster and more
robust communication platform, there is an expectation that standards would further escalate
next year. There is also an expectation of teams undertaking advanced topics such as game
theories or evolutionary algorithms to create a more involved competition.
The following proceeding entails the team effort in both the leagues. We hope this
serves as a good guideline for teams hoping to succeed in coming years. In conclusion, we
express our excitement at this year’s participation and hope that more colleges take this up as
a serious international level research.
Editors:
Kaustubh Tripathi
Sanjiban Choudhury

2
From the Federation’s desk
RoboCup is an international initiative, with the goal of fostering artificial intelligence
(AI) and robotics research and education by providing standard problems for which
solution a wide range of technologies can be integrated and tested. The original
standard problem was robot soccer. The concept of soccer-playing robots was
introduced in 1993, aiming at launching new challenges for AI and robotics,
concerning the coordination of robot teams, whose members cooperate to handle
highly dynamic and adversarial environments. Different RoboCup Soccer leagues
were created, so as to tackle different research topics, from robot control to task
planning. Over the years, new problems and leagues were introduced: RoboCup
Rescue, RoboCup@Home, extending the concept of cooperative robots to
cooperation with humans. RoboCup Junior was also launched in 2000, targeting high
school students, so as to attract them for Science and Technology through Robotics.

The first official RoboCup World Championship games and conference were held in
1997 at Nagoya, Japan with great success. Since then, the event has travelled across
continents and has grown substantially, up to more than 2,000.00 participants from 40
countries this year in Graz, Austria. Simultaneously, large regional events, such as
German Open, Japan Open, US Open or Iran Open, take place every year.

Smaller local events are also growing every year, and represent enormous
opportunities to spread the RoboCup concept and goals to more and more countries
worldwide. RoboCup Challenge @ India 2009 is such an event, bringing RoboCup to
India, one of the largest countries in the World, and certainly the home of great
technological and scientific innovation – in other words, the perfect country for
RoboCup!

On behalf of the RoboCup Federation, I would like to thank all the organizers from
the Indian Institute of Technology, Kharagpur for taking such an initiative, namely
the General Chair and Event Organizer, Prof. Sudeshna Sarkar and the General Co-
Chair, Prof. Jayanta Mukhopadhyay, from the Department of Computer Science and
Engineering. As the former General Chair of RoboCup 2004, I know well the effort
involved in such organizations, but I am also aware of the return brought by such an
effort. I hope and expect that this will be the first step towards bringing RoboCup to
India.

A special word for Mr. Aamir Ahmad, the responsible person for the event, and the
one who actually dreamed about bringing it to Kharagpur in the first place. Great
achievements start with dreams like this, and I would like to congratulate Aamir and
wish him all the best in his future efforts to promote Robotics, particularly RoboCup,
in India, with his enthusiasm and energy.

Pedro U. Lima
(RoboCup Federation Trustee,
Associate Professor at Instituto Superior Técnico, TU Lisbon, Portugal)

3
Contents

1. Introduction to Small Sized League 5

2. SSL Team Descriptions

KGPTigers 6
IRL RC 12
LesInvincibles 15
FootBots 22

3. Introduction to Simulation League 26

4. Simulation League Descriptions

Nikhil Somani 27
Rasha Eqbal 30
Dheeraj Kumar Singh 33

5. Acknowledgement 36

4
 Introduction to Small Sized
League

RoboCup is a competition domain designed to advance robotics and AI research through a

friendly competition. Small Size robot soccer is one of the RoboCup league divisions. Small
Size robot soccer, or F180 as it is otherwise known, focuses on the problem of intelligent
multi-agent cooperation and control in a highly dynamic environment with a hybrid
centralized/distributed system.
A Small Size robot soccer game takes place between two teams of five robots each. Each
robot must conform to the dimensions as specified in the F180 rules: The robot must fit
within an 180mm diameter circle and must be no higher than 15cm unless they use on-board
vision. The robots play soccer on a green carpeted field that is 4.9m long by 3.4m wide with
an orange golf ball. Robots come in two flavours, those with local on-board vision sensors
and those with global vision. Global vision robots, by far the most common variety, use an
overhead camera and off-field PC to identify and track the robots as they move around the
field. The overhead camera is attached to a camera bar located 4m above the playing surface.
Local vision robots have their sensing on the robot itself. The vision information is either
processed on-board the robot or is transmitted back to the off-field PC for processing. An off-
field PC is used to communication referee commands and, in the case of overhead vision,
position information to the robots. Typically the off-field PC also performs most, if not all, of
the processing required for coordination and control of the robots. Communications is
wireless and typically uses dedicated commercial FM transmitter/receiver units.
Building a successful team requires clever design, implementation and integration of many
hardware and software sub-components into a robustly functioning whole making Small Size
robot soccer a very interesting and challenging domain for research and education.
This year we saw excellent applications in the robot design, communication system, fast and
accurate vision as well as innovative strategy. Team strategies ranged from using a potential
based system which developed intuitive roles of players, a layered strategy approach, a role
based strategy switching and a play book approach. The mixture of these various innovative
strategies made this year’s collection of work truly remarkable.

5
 KGPTigers 2009 Team Description
K.Tripathi1, S. Choudhury2, B. Sarkar 3, K. Bairagi4, N. Kumar5 , S.Desai6
1,3,5
Department of Computer Science and Engineering
2
Department of Electrical Engineering
4
Department of Electronics and Electrical Communication Engineering
6
Department of Biotechnology
Indian Institute of Technology, Kharagpur
Kharagpur – 721302, India
1
kaustubh.iitkgp@gmail.com
2
sanjiban.choudhury@gmail.com
3
bittusrk@gmail.com
4
kinshuk.1989@gmail.com
5
naveeninkgp@gmail.com
6
sompod.daddy@gmail.com

Abstract— In this paper we present the overview
of KGPTigers team, our entry for RoboCup
Small-Sized League in RoboCup Challenge @
India 2009. Since this is the first entry for our
team, the whole infrastructure is discussed. In
addition to implementing existing algorithms,
the paper introduces original design and
solutions to problems faced along the way. A
summary of the vision, hardware and strategy is
also discussed.
Keywords — RoboCup, KGPTigers, SSL Team
Description, Multi-agent differential drive
systems.
distortion in both the cameras. So before calibration
these images we remove the radial distortion in
both the acquired images.
The camera interface communicates with the
strategy interface using a UDP connection. The
camera interface sends the information about the
coloured regions detected after thresholding. The
strategy interface then creates an environment
using the received information and decides on the
actions to be taken by various robots.
The strategy interface is also connected to the
Referee Box to receive commands from the referee
about the state of play.

I. INTRODUCTION The central marker is reserved for the team colour

markers i.e. blue or yellow. There is also a header
KGPTigers is IIT Kharagpur’s first ever entry
marker that has a unique colour on the bot, which
into the RoboCup SSL league. The work that went
determines the angle of the robot. There are also
behind this entry was to develop the whole
other identification markers of a different colour.
platform to control multiple agents and engage
The number of these identification markers, along
them in the game of soccer. The paper is divided
with the header marker uniquely identifies the
into the following sections – the vision system, the
robot.
hardware system and the intelligence architecture.
Along the way, we also discuss the problems faced
and the solutions arrived at. The paper concludes III. ROBOT HARDWARE
with prospects for future developments. The robots used are MIROSOT-100 robots which
formed the basic platform on which we built
II. VISION around.
We use two CCTV cameras along with a frame
grabber to get the images for each half of the field.
The two cameras are placed above the centre of
each half. The frame grabber is used to get a YUV
image of the two halves. YUV images provide for a
better thresholding for detection of coloured blobs
as chromatic and intensity components are separate
in a YUV image. The thresholding is done before a
game using the Camera Interface program written
specifically for this purpose. There is a radial

6

Figure 1. The MIROSOT -100 robots
Figure 2. Specification of robot
We added a shell as a protection around the robot.
Lithium ion batteries with charge capacity of 2000
mAh were attached. The kicker system was
developed using an open frame, push type solenoid.
Figure 3. Open frame, Push type solenoid.
7
This solenoid was mounted on top of the robot and
on being activated pushed an aluminium frame.
The schematic is as shown in figure 4.
Figure 4. The kicker mechanism
The logic behind this design was that since rolling
friction is very less, there is no significant force
opposing the solenoid. Hence the velocity of the
ball is the velocity of the ball when it leaves the
‫ܮ‬
frame.
‫ݒ‬௕௔௟௟ = ൬ ൰ ∗ ‫ݒ‬௦௢௟௘௡௢௜ௗ
݈ଵ
where ‫ ≅ ܮ‬3 ∗ ݈_1 creating a high speed for the
ball.
Figure 5. Robot shell
III. Motion Planning and Implementation of
Strategy
The motion planning algorithm is designed to
control the movement of 5 robots simultaneously,
avoiding collision with each other and opponent
robots. For such applications, a real time path
planning approach is required which is sub-optimal
but adheres to strict time constraints. Coupled with
this, a generic strategy structure is required which
directs the movements of the robots and responds
to field configurations and situations.
A. Prediction of the world model
The frame rate after visual segmentation drops to
an average of 2 fps. This rate isn’t fast enough for
the corrective feedback required to keep robot
following designated path. Moreover, a certainly
positional uncertainty is associated with the robot
and the ball. During calculation of angles of robots,
both uncertainties couple and the standard
deviation of error increases.
We thus use Kalman Filters [7] for prediction of
the world model and to remove positional
uncertainties as much as possible. For the ball
model, a simple linear Kalman filter is used as
shown
increasing dimensions. Also these algorithms are
incremental in nature allowing robot specific
constraints to be encoded in the algorithm.
Specifically we modify the ERRT [3] (Extended
Rapidly-exploring Random Trees) algorithm which
had a very good success rate. To implement the
algorithm a KD tree was used with bi-directional
searching.
function RRTPlan (env:environment, initial:state,
goal:state):rrt-tree
var nearest, extended, target:state;
var tree:rrt-tree;
nearest := initial;
rrt-tree := initial;

‫ݔ‬
while(Distance (nearest, goal) <

‫ݕ‬
ܺ௕௔௟௟ = ൦‫ݔ‬ሶ ൪
threshold)
target = ChooseTarget (goal);

‫ݕ‬ሶ
nearest = Nearest (tree, target);
extended = Extend (env,
(1) nearest,target);
if (extended != EmptyState) then
Since the robot is a differential drive, it is better AddNode (tree,
modelled by extended Kalman filters since its extended);
motion is non-linear. The state space model for the return tree;
robot is

‫ݔ‬
function ChooseTarget(goal:state):state
‫ݕ‬
ܺ௥௢௕௢௧ = ൦ ൪
var p:real;

ߠ
var i:integer;

ߠሶ
p = UniformRandom in [0.0 .. 1.0];
i = UniformRandom in [0 ..
(2) NumWayPoints-1];
if (0 < p < GoalProb) then
The filters have several advantages – return goal;
1. Given a time stamp, the postion of the ball else if (GoalProb < p <
and the bot can be predicted. GoalProb+WayPointProb) then
2. The filter can be tuned to converge faster return WayPointCache[i];
at the same time tolerating greater error by else if (GoalProb+WayPointProb < p < 1)
increasing the process noise. then
3. Occlusions may occur in the image return RandomState();
processing where certain frames may miss
the robot, which can be handled by the function Nearest (tree:rrt-tree,target:state):state
Kalman filter. var nearest:state;
nearest := EmptyState;
B. Real time path planning for each state s in current-tree
if (Distance (s,target) < Distance
The path planning is treated as a black box module (nearest,target)) then
whose input is the initial and final configuration nearest := s;
and output is expected to be the series of return nearest;
intermediate states to reach the configuration
respecting constraints. The condition also demands Table x: The outlay of the ERRT approach to path
that the module be a “hard real time system”; planning.
failure to output the path within a given interval T
would mean complete failure. Other issues are state This algorithm was primarily meant for omni-
discretizations, efficiency v/s accuracy trade-off directional robots which have less constraints than
and respecting kinematical constraints. the differential drives that we used. Hence, the
We adopt the method of RRT [3] (Rapidly- following improvements were applied by us –
exploring Random Trees) as a basis for out path
planning. The ingenuity of the method lies in the 1) Generated path must be smooth –
fact that it doesn’t delve into state discretization Differential drives have a limitation in their
and thus prevents the explosion of nodes with

8
 kinematics when it comes to changing the heading
of their movements. As a result, we approach the
issue of turning with the dual aspect of stopping
completely and turning, as well as turning while
moving maintaining a fairly large radius of
curvature so the centripetal force is not enough to
topple the robot. Thus we modify the algorithm for
Extend() function as follows:
function Extend(env, nearest, target,
overwrite_flag):state
var extended_node:state;
if(nearest==start && target==goal ||
overwrite_flag == 1 ) then
extended_node :=
Create_node(nearest, unit_dist, angle(nearest,
target));
else if(angle(nearest,target) >
thresh_angle) then
extended_node :=
Create_node(nearest,unit_dist, thresh_angle);
else
extended_node :=
Create_node(nearest, unit_dist, angle(nearest,
target));
return extended_node;
Table 1 : Modification of Extend function
The above modification results in smoother
trajectories and drastic turn only in the cases to face
the ball or when triggered by a flag. This flag is
triggered under time constraints as explained later
on.
2) Implementation of hard real time system – The path
planner has to return any solution within a time T.
So after time T/2, it activates a drastic flag which
demands any non-smooth trajectory to take itself
out of deadlock situations. After tine T, the nearest
state to goal is taken and that series of paths is
chosen.
3) Improving search speed by introducing a 3rd
dimension to KD tree – The current search method
used a 2-dimensional KD tree for faster searching.
We also introduce a 3rd dimension sorted according
to heading so that we can find the point closest in
heading to the previous point
4) Dynamic radii change of safety circles – Obstacle
collision is prevented by generating a safety circle
around each bots which has a radius of
2*bot_diameter. While this results in trajectories
well away from each other, sometimes a robot
needs to pass through the gap between two bots. If
the gap is feasible enough, but less than
4*bot_diameter, the path will not be generated and
9
a far less optimal path around both obstacles will
be tried. In such cases, the radii is reduced just
enough to squeeze an opening through the
obstacles.
Figure 6. Screenshot of the path planner GUI
The above screenshot shows in red the planned
path of each robot, as well as the orange ball at the
centre. The coloured rings around the robots
represent the safety radii, the colour standing for
the perspective of the particular robot.
C. Strategic implementation
MAPS (Multi-Agent Planning System) is a method
of controlling multiple robots in a highly dynamic
environment like Robocup. It uses Potential fields
to create a high-level abstract representation of the
robot’s environment at a particular point of time.
From these fields obtained, strategic commands are
sent to each robot like ‘Kick the ball to a good
position’ or ‘Run to a good position’. [5]
We use MAPS to plan strategies only during
‘normal’ course of the play. Under extreme cases
of defensive and offensive plays we leave aside
MAPS and greedily decide the course of action.
The actions of the goalie are not determined by
MAPS.
The classical MAPS algorithm:
Update robot and ball coordinates from vision
system
Build a field to determine robot actions
for each robot
if the robot is best to kick the ball
Build a ‘kick to’ working field
Send ‘kick to’ command and coordinates
to robot
else if we are in control of the ball
Build an attacking ‘go to’ field
else
Build a defensive ‘go to’ field
 Send ‘go to’ command and coordinates to Defending in extreme situations: When an
robot opponent is very close to our goal, the closest
end teammate goes for the ball and others get in the
way of the attacker and the goal to prevent a goal
from being conceded.
1) MAPS Implementation

The playing field is divided into an integer array of

dimensions 38x28. The integers represent the
potential of that area. Then a series of potential
fields are built on an empty equi-potential field. At
last, MAPS decides for each robot its next course
of action by finding the minimum value in the
array.
The Potential Fields used are:
(i) Base Field: The array is filled with values
decreasing towards the opponent goal,
thus biasing the play towards the opponent
goal.
(ii) Distance Field: In order to avoid giving
orders to shoot to long distances a field is
created in which the value of a square is
proportional to its distance from the ball. Figure 7. The potential field
(iii) Robot Influence Field: It makes a small Above is a snapshot of the simulator showing an
region around the robots repulsive or attacking go to field for blue robot lowest in the
attractive depending on the situation. Say, picture. This field did not add the Clear Path To
we require a attractive field around the Goal Field. The black circle represents the point
teammates when trying to pass the ball returned to this robot by MAPS to go to. Potential
and a repulsive region in order to avoid and thus repulsiveness decreases from darker to
crowding. lighter regions.
(iv) Clear Path to Ball Field: It makes a region
repulsive where it is not possible to kick D. Differential drive control for position
the ball to, like the regions behind the
[6]. If we want our drive to turn from ߠଵ to ߠଶ then
robots from the point of view of the ball. We use a set of reactive equations for robot control
(v) Clear Path to Goal Field: It makes a region
repulsive from where the view of the goal let

∆ = ߠଵ − ߠଶ
is obstructed. This helps the players to go
to a better position to receive the ball and (1)

ሺ‫ݐ‬, ‫ݎ‬ሻ = ሺܿ‫ ݏ݋‬ଶ ∆ ∗ ‫݊݃ݏ‬ሺcosሺ∆ሻሻ ,

shoot.

2) MAPS Command Fields: ‫݊݅ݏ‬ଶ ∆ ∗ ‫݊݃ݏ‬ሺsinሺ∆ሻሻሻ (2)

(i) Kick To Field: All the above fields except ‫ݒ‬௟ = ‫ݒ‬ሺ‫ ݐ‬+ ‫ݎ‬ሻ (3)

‫ݒ‬௥ = ‫ݒ‬ሺ‫ ݐ‬− ‫ݎ‬ሻ

the last are built and added together. The
point corresponding to the lowest value is (4)
the desired ‘kick to’ coordinate.

(ii) Go To Field: All of the above fields are
built and added together. For an attacking
Go To field, the opposition goal is
considered for the Clear Path to Goal Field
and the lowest point is chosen. It’s the
reverse in case of a defensive Go To field.
Attacking in extreme situations: When very close
to the opponent goal, a shooting situation is
checked for existence. If it is the ‘Kick To’ field
commands to shoot the ball at the opponent goal. If
it isn’t MAPS takes over the decision making.
speed by ‫ݒ‬.
The above set of equations bound any wheel’s
IV. CONCLUSIONS
In the coming years we will work to improve the
present system drastically. Working in this fast
real-time environment has given us an idea of the
speed and desired robustness.
From the hardware’s perspective, new omni-
directional robots with intelligent controllers will
be manufactured.

10
 The vision system would be more robust, with
dynamic localisation techniques and adaptive
thresholding.
The strategy system will be made completely
intelligent through training environments and
neuro-fuzzy controllers. Also at an higher level,
game theory will be incorporated to model
opponent tactics.

ACKNOWLEDGMENT
We would like to thank the Department of
Computer Science and Engineering for the
immense help and advice in this area. Without their
aid, procurement and organization of the project
would have been impossible.
We would also like to thank all concerned
professors – Prof J. Mukhopadhya, Prof S.Sarkar,
Prof D.K.Pratihar and Prof G.Harit for their
invaluable advice.

REFERENCES

[1] Bruce, J., Balch, T., Veloso, M.: Fast color image
segmentation for interactive robots. In: Proceedings of the
IEEE Conference on Intelligent Robots and Systems,
Japan (2000)
[2] Bruce, J., Veloso, M.: Fast and accurate vision-based
pattern detection and identification. In: Proceedings of the
IEEE International Conference on Robotics and
Automation, Taiwan (May 2003)
[3] Bruce, J.R., Veloso, M.: Real-time randomized path
planning for robot navigation. In: Proceedings of the
IEEE Conference on Intelligent Robots and Systems.
(2002)
[4] Akiyama, J: Adapting the multi-agent planning system
for Robocup Simulation. In: University of Queensland,
Bachelor thesis.
[5] Tews, A, Wyeth, G: MAPS: a system for multi-agent
coordination. In: Advanced Robotics, Vol. 14, No. 1, pp.
37–50 (2000)
[6] Bowling, M, Veloso, M. Motion Control in CMUnited-
98. In Proceedings of IJCAI-99 Workshop on RoboCup,
pp. 52–56, 1999
[7] Kalman, R. E. 1960. “A New Approach to Linear
Filtering and Prediction Problems,” Transaction of the
ASME—Journal of Basic Engineering”, pp. 35-45
(March 1960).

11
 RoboCup Team SSL Description, IRL RC
B. Sujith Kumar1, P.S. Abhimanyu2, P. Naga Satish3, Ch. Abhishek4,
B.V.V.P. Bhargav5, N.Venkat Abilash Reddy6
Department of Electronics and Communication Engineering,
International Institute of Information Technology,
Hyderabad, India.
1
sujithkumar@students.iiit.ac.in
2
abhimanyu_p@students.iiit.ac.in
3
satish_pn@stdents.iiit.ac.in
4
chabhishek@students.iiit.ac.in
5
bvvp_bhargav@students.iiit.ac.in
6
abilashreddy@students.iiit.ac.in

Abstract— This paper describes the robot system of IRL

RC which is going to participate in RoboCup,09 India.
The whole system is divided into three main parts:
Mechanical, Electrical and Software systems. A summary
of all these systems is given in different sections. Also the
drawbacks and our future plans are discussed.

Keywords— Robocup, IRL RC, IRL, TDP, Team Description

Paper.

I. INTRODUCTION
Robotics is an area where many technologies and fields can
be merged. It also develops the ability to solve real time
problems. In this paper we explain about our robotic system
and our plans to participate in RoboCup2009, India. Fig. 1 CAD of IRL RC Omni Directional Bot
This is the first time national wide RoboCup being held in
India. So, we formed a good team with very interested people
in Robotics.
This paper is organized as follows: Section II describes the
mechanical system of the robot. Section III describes the
electrical and electronic elements involved. Section IV
describes the software system focusing on two important parts
namely the vision system and the decision system. Section V
is about the drawbacks of our very first attempt. Section VI
deals with our future plans to participate in the next RoboCups.

II. MECHANICAL SYSTEM

The robot is omnidirectional with four custom made
Sweedish wheels. Any two wheels are separated by an angle
of 120o or 60o. Each wheel contains sixteen symmetrically
aligned similar rollers and each roller is parallel to the axis of
rotation of the wheel to give an extra degree of freedom.
These wheels are attached to stepper motors of the type 16PU-
M301-G1.
The robot’s CAD is given in Fig. 1 and the original robot’s
picture is given in Fig. 2. Fig. 3 shows the horizontal cross
section of a robot. The robots well fit into the restrictions of
SSL rules. Each robot has a diameter of 179 mm and a height
of 150 mm.
Fig. 2 IRL RC Bot
Dribbling system consists of a rubber roller attached to a
metal rod which is rotated by a simple DC brush motor as
shown in Fig. 4.
The width of the front part of the robot is 100 mm so as to
give the ball enough compartment and the dribbler covers
19% of the ball.
The kicking system consists of a spring which is to be
compressed and released by a high torque servo motor.

12
 Fig. 3 Horizontal Cross Section of IRL RC Robot
Fig. 5 IRL RC Central Controller

Fig. 4 IRL RC Dribbling Mechanism

Fig. 6 IRL RC Motor Driver Circuit

III. ELECTRICAL SYSTEM

IV. SOFTWARE SYSTEM
The central controller consists of one ATMega16 and one
ATMega8 microcontrollers. ATMega16 communicates with
Our software system is divided into two different entities;
the Maxstream XBee Seies 2 modules at a baud rate of 9600
one is Vision System and the other one is Decision System.
bps. These modules are low power RF devices which work on
They communicate with each other using UDP through socket
Zigbee protocol. Each of the RF devices is embedded in each
programming. Their descriptions are given below.
bot and they communicate with the XBee module connected
to the Decision System. The command from the Decision A. Vision System
system to the bot contains the information about the speed of
We are using Unibrain Fire-I firewire digital camera ( IEE
each wheel, dibbling on/off and kicking on/off.
1394 ) which supports 30 fps in the mode YUV 4:1:1 with a
ATMega8 generates required signals for the dribbling and
resolution of 640 X 480.
kicking. It acts a slave to the main controller – ATMega16.
We are using openCV open source library for all the vision
The stepper motors are driven by L298-L297 pairs. The
process. Our algorithm first finds the centers of the robots and
driver circuit for the stepper motor consists of four L298-L297
the ball in a frame using thresholds in YUV space discarding
pairs connected to ATMega16. The servo motor and the
the Y channel to compensate the effects caused by the
dribbler roller motor are driven by one L293D connected to
illumination changes. We have used our own extension of the
ATMega8. algorithm described in [1] which can determine the ids of the
Our custom made double layered PCBs for the central
robots and their orientations robustly.
controller and the driver circuits are given in Fig. 5 and Fig. 6
This system sends the bots’ positions, their orientations and
respectively.
the ball’s position to the Decision System in a UDP using
The whole electrical system is driven by a 11.1 V, 2200
socket programming in Linux. We’ve chosen UDP because it
mAh Li-Po battery. To cool the electrical system we use a
is connectionless and it does not do error correction and flow
CPU fan which consists of 12V DC brushless motor. control as in TCP which is slower compared to UDP.

13
B. Decision System
The decision system receives the information, described
above, from the vision system and sends appropriate
commands to the robots wirelessly.
Our decision system along with the controlling of the on
filed bots is divided into four layers. The bottom layer, layer 1,
consists of sending particular control commands, like
frequency of the stepper motor steps, to the bots using serial
communication and the XBee devices. Next level layer, layer
2, uses the layer 1 and sends particular control commands like
setting the wheel velocities independently. Layer 3 consists of
commands which are used to move the robot at a particular
speed in a particular direction with particular angular velocity
about its center. The strategic part is in Layer 4. The
advantage of doing this is that even if we change the robot’s
type (differential drive or omni directional) we have to change
only the Layer 1 while the remaining layers will remain intact.
V. DRAWBACKS
We are using stepper motors to have a better performance
in terms of controlling the speed of a wheel. The steppers
motors run in steps because of which they create vibrations
which combine with the vibrations produced by the Sweedish
wheels. Also, torque of the stepper motors decreases with
increasing speed. It decreases with larger slope after a cut off
speed than before the cut off. Because of the vibrations and
decreasing torque we are not able to get precise control over
the robot’s locomotion.
Because of the limitations in the number of timers/counters
in ATMega16, the discrete speed values given to the motors
are very less in number with which we are not able to use any
control theory.
Because of the lack of resources, we are not able to use a
good and robust kicking device.
VII. CONCLUSION
We’ve done all the basic parts needed to participate the
competition. Some of the ideas belong to us and some of the
ideas are adopted from the international teams. Major part of
the control systems and algorithm parts are developed from
the knowledge we’ve gained from the courses: Embedded
Robotics, Mobile Robotics, Intro to Robotics, Linear Control
Systems, Electro Magnetic Theory, Electronic Workshop,
Computer Vision etc., offered in our institute. We are also
thinking of implementing Neural Network algorithms on our
next generation robots.
REFERENCES
[1] Shichi Shimizu, Tomoyuki Nagahashi, and Hironobu Fujiyoshi,
“Robust and Accurate Detection of Object Orientation and ID without
Color Segmentation”.
Oliver Purwin, Raffaello D’Andrea, “Trajectory generation and control
for four wheeled omni directional vehicles”, Robotics and Autonomous
Systems 54 (2006) 13–22.
[2] Robert L. Williams, II, Member, IEEE, Brian E. Carter, Paolo Gallina,
and Giulio Rosati, “Dynamic Model With Slip for Wheeled
Omnidirectional Robots”, IEEE TRANSACTIONS ON ROBOTICS
AND AUTOMATION, VOL. 18, NO. 3, JUNE 2002.
[3] Maxstream XBee module user manual. [Online]. Available:
http://www.johnhenryshammer.com/TEChREF/xbeePage/series2/prod
uct-manual_XBee_Series2_OEM_RF-Modules_ZigBee.pdf
[4] http://robocup.mi.fu-berlin.de/pmwiki/pmwiki.php
[5] http://wiki.robojackets.org/index.php/RoboCup

VI. FUTURE PLANS

We will continue the spirit to participate in the future
national wide Robocup Competitions and will definitely be a
part of its motto to encourage the AI research in India.
We need to look at our drawbacks and we have to come up
with effective engineering designs which can reach the
international level.
Our central controller must be changed to cope up with the
increasing complexity. The motors must be changed to have a
smoother control and the wheel’s structure has to be
redesigned. We have to design a new kicking device using
solenoids and the control of it.
The vision process has to be robust and it should be
stabilized for use in our future participations. We will try to
use neural networks for the decision system to reduce the time
delay produced by various factors.

14
 LES INVINCIBLES
TEAM DESCRIPTION FOR ROBOCUP 2009
S.Amar Nath#1, Aditya Swaroop Joshi#2, Akshay S Fadnis#3,
Atul Khardekar#4, Anil Kumar Sistla#5
#
Department Of Electronics and Communication Engineering, CVR College Of Engineering
#
Department Of Electronics and Instrumentation Engineering, CVR College Of Engineering

CVR College of Engineering,

Ibrahimpatan, R.R.District
Hyderabad,India.

1
amar@ielectron.com
2
aditya2303@gmail.com
3
akshaysukumarfadnis@gmail.com
4
atulkhardekar@gmail.com
5
mrcool.anil@gmail.com

Abstract— This paper describes the currently developed LES

INVINCIBLES robot soccer team. We present an overall
perspective for the entire system which consists of 4 major
systems which operate in tandem with each other: mechanical,
electrical, vision, and AI.
Keywords— Decision Making Trees, Real Time Synchronized
Image Processing, Overcoming Computer vision based latency
issues
I. INTRODUCTION
LESINVINCIBLES is a robot soccer team from the
Electronics and Communication Engineering Department of
CVR College of Engineering, Hyderabad, India.
Our team specializes in an arsenal of robotic disciplines
which encompass many fields of engineering. Our notable
achievements include a PC controlled Surveillance Vehicle
which used an onboard mobile to communicate with the host
PC through GPRS (Using J2ME and IRDA to communicate
with the microcontroller) and transmitted its coordinates at
regular intervals of time as well as snapshots of its
surroundings at periodic intervals.
This is our first entry in a Robocup Event (International or
Regional), hence we plan to showcase the very best that Team
LESINVINCIBLES has to Offer. We also wish to take our
efforts put into this competition into our foray and possibly
represent our College in the international event, given our
unique accomplishments in this equally noteworthy venture.
2 MECHANICAL SYSTEM
Our Mechanical Design is a culmination of over a year of
research in various Steering Systems. Owing to our
continuous robotic pursuits, we have gained a lot Of
experience owing to which we have achieved a reliable
mechanical design for a non holonomic robotic platform given
the inopportune unavailability of Mecanum wheels in our
vicinity. The mechanical design for 2009 is aimed at
developing a Reliable and robust platform upon which we can
pursue further research .We have experimented for the first
time in our ventures with PLEX which promises to be a
worthy replacement for Aluminum given its outstanding
Shearing Stress withstanding ability and high molecular
density.
2.1 Summary:
This year, our fundamental goals are focused on developing
a fast,robust ,hassle free Platform for carrying out Research
in the multi-Agent Decision Making Domain, more so in the
field of Soccer as it has from time to time proved to be an
excellent foundation for this field of Research given its real
time as well as Statistical decision making requirements. At
the time this report was being written, each robot had a
diameter of 170 mm, height of 141 mm, and weight of about

15
3.8 Kg. Our robots can carry out different strategies with ease
given their builds as well as carry out very successfully
counter offense as well as defensive manoeuvres against
opponents, and interrupt their plays effectively. Our Achilles
Heel though this year may undoubtedly prove to be our
kicking mechanism which only uses a motor which is made to
rotate at a maximum angle of 22.5 degrees at various
Pulse width modulated speeds. We are working on building a
better kicking system currently using a lock-and-load
mechanism through springs and a motor.
Our Electronic circuitry is a minimalists dream owing to
efforts put in to use components which would justify their
usage rather than those which would sound highly technical
but seldom justify the rather time consuming routines put into
understanding their usage.
We took a leaf out of the book of The World Champions
Team PLASMA-Z and developed a simple motor based
dribbling axle with a groove on it in order to make the ball
roll into the grooved shape which makes the ball stay put for a
very short instant in the center of the robot which would
enable accurate kicking. Simple yet lethal, this system is very
effective since it presses the ball against its own weight.
.
3 Electrical System
The major components are the processing module, the
motor driving
Module and the wireless communication module.
The Express PCB Drawings of the respective circuits are
affixed below,

THE PROCESSING AND WIRELESS COMMUNICATION MODULE

ON EACH ROBOT

2.2 DRIVING SYSTEM

TEAM LES INVINCIBLES currently uses a non
holonomic differential drive. With two DOF (degrees of
freedom) for a given instant in the Y and Z axis Respectively.
We used 750 RPM 12 Volts driven Dc motors given the
spectacular speed requirements of this beautiful Competition.
Considering the high torque requirement, diameter of the
wheel is quite large. A practically achievable robot’s forward
average speed of 1.26 m/sec was a noteworthy achievement
given our first outing in a venture like this.
We used off the shelf rubberized high traction
wheels to facilitate skid steering as we didn’t want to deviate
too far from the basic building blocks of our pursuits in
robotics.

2.3 SHOOTING SYSTEM

As aforementioned , Our Kicking System is rather a crude
implementation as the DC-DC converter used in the
preliminary tests for a solenoid based kicking device didn’t
have the required efficiency, moreover the solenoid’s limited
kicking power didn’t necessitate the need for further research
as we had to manage with very limited resources
Using a MOSFET and a 60 RPM motor, locked at a
maximum angle of 22.5 degrees using a gear head, we could
manage a basic but decent shooting system using a Pulse
width Modulated scheme

2.4 DRIBBLING SYSTEM

The dribbler spins the ball backwards to the center of the
robot, so that the soccer bot can handle possession of the ball
while turning around with relative ease.

16
 THE MOTOR CONTROLLER MODULE ON EACH ROBOT (TWO
WERE USED ON EACH ROBOT,ONE FOR THE STEERING OF THE
VEHICLE, THE OTHER FOR THE KICKING AND DRIBBLING
DEVICES)
THE RF SERVER CIRCUIT CONNECTED TO THE HOST PC
THROUGH A RS232-TTL ADAPTER (SOFTWARE BASED UART
WAS EMPLOYED FOR THE SERIAL INTERFACE AND HARDWARE
UART WAS USED FOR THE RF MODULES)
Our resources for this competition were not extravagant.
Yet, our competitive spirit kept our dreams alive and we
17
managed to come up with a simple yet elegant Electronic
design.
Each robot consisted of a 434 MHz transmitter and receiver
pair which could manage a data rate of 4800bps (Around 600
Bytes Per Second).This data rate had to be effectively halved
as, in order to manage reliable communication, we used a
slightly less computationally expensive version of Manchester
Encoding which used alternate odd byte encoding2 which
enabled a practically usable data rate of around 280 Bytes per
Second which was just about enough. More on this will be
disclosed in the Software section. We used the help of our old
Ally an L293D H-Bridge with a subtle twist though, to
develop a motor controller which provides unique BACK
EMF1 inputs provided back to the ADC Inputs of the
microcontroller on the wireless communication board through
simple resistive voltage dividers in order to scale the voltage
to a range which the ADC onboard the microcontroller could
read.
A RF-Server like implementation was provided to
enable wireless communication between the Host PC with
circuitry closely matched to that of the wireless
communication on each robot with the exception of the
addition of a RS232-TTL adapter. The MCU program written
for that circuit was a simple stack based State machine which
sent designated commands from the Host Application On the
PC to the robot soccer players through Manchester Encoding
and player addressing in a Round-Robin Interrupt driven
fashion.
4 SOFTWARE SECTION:
I) Vision System
In this system we used 2 Microsoft USB based lifecam
cameras for capturing the soccer field, then sent the images to
the vision computer for processing. Subsequently, detection
of the position of our robots, the opponent robots, and the ball
was carried out. This filtered data was condensed and packed
into a “Color,Centroid coordinates” string and then was sent
to an another application through UDP which managed the AI
part.
=> Image Capture:
We used Java as our platform for developing the
image processing as well as the Soccer Applications. Our
Initial approach of offloading the entire image processing
application onto the GPU using JOGL couldn’t be realized in
time before this competition and hence we had to withdraw
from doing so.
We used “DSJ” a direct show wrapper for Java
instead of JMF as the basis on which we developed our image
processing applications. Two instances of DSJ run separately
each transmitting live feed from the two respective Cams. We
used two cams in order to ensure that the whole field was
covered.
 => Image Processing:

For the image Processing Part, we took the help of

J.Bruce’s Thesis3 on his very fast CMVision library and
developed our own library with the following
Modifications:

Run length encoding was included as a part of the color

thresholding pass itself rather than two separate passes on the
same Image to avoid the time overhead.
Getting regions from the run length encoded array was
implemented in an
N*N times pass where N is the no of runlength encoded
elements

Our approach did prove to be very successful and we can

confidently say that we as of now have one of the fastest
image processing libraries written in java with a frame
overhead of around 32 ms for a 160*120 picture

TEST IMAGE THRESHOLDED IMAGE

18
 The steps in the vision part can be summarized as follows:
• Images were captured from two separate cams
simultaneously using two instances of a DSJ based
capture application.
• The two Images were then thresholded using a LUT
based approach identical to the one implemented in
CMVision approach and runs of similar colors along the
same row were grouped .
• The run length encoded array was then scanned for
similarly colored vertical neighbours for a maximum of
4 Rows ( Top-Down approach for vertical connectivity)
• The gathered regions were then filtered in a pass to
filter out those only which satisfied a minimum area
criterion defined in a file which include color
definitions as well as other criterions
• The data to be sent to the Soccer AI Application
consisted of relevant color arrays along with the
centroids and areas of regions which passed the filtering.
The data was then transmitted through UDP (local
host:127.0.0.XX) to the Soccer AI Application
II Low level functions:
An elementary model of the differential drive
system was developed based on the following equations5,
The PWM values are theoretically
proportional to the wheel speeds and hence they are sent
directly to the microcontrollers rather than the wheel speeds to
avoid the overhead of numerical computation given a very
small time frame of 30 ms.
The obtained PWM values were then passed
through a Proportional-Integral-Derivative Controller and the
desired PWM Values
were calculated based on the equation6
19
The entire code for the embedded part was written in
Codevision AVR Compiler TM (Receiver and motor controller
parts) and MikroElektronika mikroC PRO for AVRTM
Compiler (Transmitter part)
III Soccer AI development
This was by far not a walk in the park for us given
our lack of multi-agent research and hence we nose-dived
straight into the realms of multi-agent research
Our Soccer AI application mainly consisted of the
following modules:
• RAW Vision Parser which received the “Color
coordinates” string from the Vision Application
• A World Manager which provided updates to the main
AI module based on events from the Vision parser as
well as the User regarding time of the match, pixel to
distance ratio calculation as well as the calibration for
the differential drive systems of the robots.
• A SerialCommunications Manager which sent the low
level PWM commands to the RF Server circuit which
in turn sent them to the robots in a
“PLAYER_ID,LEFTMOTOR_MOTION_SIGN,RIGHT_
MOTOR_MOTION_SIGN,KICK_MOTOR_MOTION_S
IGN,DRIIBLING_MOTOR_MOTION_SIGN,
LEFTMOTORPWMVALUE,RIGHTMOTORPWMVALU
E KICKMOTORPWMVALUE ,
DRIBBLINGMOTORPWMVALUE “ style packet.
• A Kalman Filter based ball tracker (Only First degree
Taylors Expansion was used).
• A state machine based instruction processing module
which processed simple commands received from the
World Manager such as
i. KICKOFF
ii. HALFTIME
iii. PLAYERFOULED (int player_ID)
iv. UPDATEGOAL(int…TEAMID)
The respective instructions were
then passed onto the functions which were defined
within the State machine.
 Our elementary block diagram can be shown as follows
The reason for separation of a Team into distinct
players can be summarized as follows:
• Each player is a Node in a Hierarchical Tree Graph
having two branches for two distinct cases 0-Not
Threatened 1-Threatened. Each case leading to an other
Node ie a player as defined in the strategy lookup table
defined in a file strategy.txt which takes the help of a
predefined formation
• The AI module uses a support spot calculator to
determine the nearest node(player) to the current node
and then sends two commands simultaneously to the
two nearest nodes(here, nearest as in distance from the
ball not from the current player)
• The first command sends any of the two players to a
position determined using a Kalman Filter which would
determine the balls future position given that the
velocity vector of the kick of the current node (player)
as well as the trajectory of the ball is known.
• The other command sends the other player to a “fail-
safe” position as in a through ball assisted maneuver at
a Gaussian calculated position which lies between
[x1, y1]-[x2.y2] where [x1,y1] are the coordinates of
the ball and [x2,y2] are the coordinates of the goal. The
above iterations from node to node as in the current
node instance occur as defined in strategy.txt based on
the weights(Threatened-Not Threatened ) with each
‘strategy’ ending when a goal counter is updated. Each
‘Strategy’ is cycled through if it is not ‘implemented
successfully’ (ie goalcounter=0 for a n maximum no of
Strategy no-X iteration (We took n=3).
• Threatened is defined in the following cases
20
i. The support spot calculator doesn’t
find any near players who are at an
equally favourable(as in distance )
from the current player as well as
the ball
ii. The next transition of the
movement vector results in a
threatened case again
As observed, our algorithm uses a directed
weights based graph hence having the probably distinctive
approach of implementing offense, defense in a simple unified
line of attack. Counter offense is not a separate behavior and
hence the offense strategy is used in the same place.
A. References
1. David Hygh’s Back Emf Article:
http://frontrangerobotics.org/PIDbackEMF/DavesBEMFmotor
Article.htm
2. An Alternative variant Of Manchester Encoding:
http://www.ottawarobotics.org/articles/rf/rf_article.pdf
-Written by Aaron Ramsey
(aaron@bottle rocket.org)
3. James Bruce’s thesis on CMVision:
http://www2.cs.cmu.edu/jbruce/cmvision/papers/JBT
hesis00.pdf
4. "Run Length Encoding" by Arturo San Emeterio
Campos :
http://www.arturocampos.com/ac_rle.html
5. Springer - Embedded Robotics, 2nd Edition-By Thomas
Bräunl
6. Microchip’s Application Note On Back Emf based
Sensorless motion control:
htp://ww1.microchip.com/downloads/en/AppNotes/00893a.
pdf
6 Conclusions
After countless hours of coding,testing,debugging and well
more debugging, we have come to a conclusion that this
competition is not for the faint hearted and hence we have put
in the best of our abilities in order to be a worthy adversary to
our opponents as well as gain some insight into this
fascinating multi-agent research based venture encountering
many and we mean many problems along the way and finding
some good solutions for some of them though we do plan to
tackle them all later in the near future. The experience we
gained results in the improvement of our team in a positive
direction. We plan to make this in our own words
“A Small Step in multi-agent Research. A
Giant Leap in cognitive Robotics”.
 ACKNOWLEDGMENT
• The Management Of CVR College Of Engineering.
• Ashish K.Sahani & Omkar C.Kulkarni for their invaluable advice
and helping us in getting the basics right.
• Our Families for bearing those torrid long nights of debugging.
• Last But Not the Least,,the people at IIT-KGP for attending to our
rather cumbersome calls without letting out the slightest frown.

21
 FootBots Team Description
Kartik Mohta, Pratik Chaudhari, Simit Pradhan,
Siraj Issani, Vishal Prabhu
kartikmohta@gmail.com
Kodihalli, Bangalore - 560 008

Abstract—This paper describes FootBots, our entry for the III. S TRATEGY
Small Size League Robosoccer at RoboCup Challenge India 2009.
Strategy selection cannot be a set of pre-defined rules due
to nature of this problem. We have used a hierarchical system
I. I NTRODUCTION that generates overall strategies as well as individual robot
Our team entry consists of multiple differential drive robots commands for these strategies. It is based upon the STP
controlled by an off-board computer. The sensing is provided structure as described in Browning et. al. [1,2] . Note that the
by two cameras mounted over the arena. The software takes following section only deals with the strategies used for the
the images from the cameras, calculates the robot commands playing robots i.e. excluding the goal-keeper, the strategy
and sends them to the individual robots. for which is separately evaluated by looking at the current
II. V ISION positions of the robots and the ball. This is done so to simplify
the strategy. It handicaps the defence however in the sense that
We use the OpenCV library for image processing. Input
there is no relation between the movements of the defence
is taken as a video stream from the two cameras in order
robots and the goalie.
to cover the whole arena and the frames are merged. These
frames are processed to get the positions of the robots and
the ball on the field. RGB images are first converted to the Camera
HSV colour-space in order to make the detections more robust
against variations in the lighting conditions. Segmentation of
the image is done using pre-defined ranges for colors in the
blobslib module of OpenCV. This results in blobs of different
Vision
colors corresponding to the colors of the robots on a black
background which is the field. The final step is to convert
the pixel values accurately to actual distances for which we
calibrate the camera before hand. Note that this is the only
source of robot position in the current implementation. World

Camera 1 Camera 2
Strategy Plays Tactics

Merge

Robot
HSV Conversion

Colour Filtering Figure 2. Strategy hierarchy

A. World
Blob Detection
As mentioned earlier, the Vision module is responsible for
generating the positions of all the objects on the field. This
includes the ball, the opponent robots, and the team robots. For
Output taking decisions regarding the strategy, we would ideally need
the velocities and positions of all the entities on the playing
field. However, extracting the velocity of the opponent robots
Figure 1. Image processing pipeline is a difficult task (without identifying them individually). If
we decide to track a particular blob to get the velocity, small

22
incidents like occlusion or mis-detection of the same blob in
consecutive frames can cause huge errors in the perceived
velocity. Hence, in the current implementation we rely only
upon the knowledge of the positions of all the opponents.
The strategy part of course knows the velocities assigned
to each team robot and its current direction. These velocities
are used in the decision making process. Thus the positions of
objects from the vision module and commanded velocities of
teammates along with their commanded orientations together
form the input to the world. It is the job of this module to keep
track of all these these things along with their time stamps to
be passed on to other decision making parts of the code.
Situation specific flags like ball-out-of-play, referee deci-
sions etc. are also stored in the world module. All the positions
are stored in the world co-ordinate frame. We can convert these
co-ordinates to robot specific coordinates to aid in calculations
of the form nearest-opponent or nearest teammate for a robot.
The path planning module takes input in the form of obstacle
positions, source position and destination position. This has
to be generated by considering the current positions of the
robots. The world module calculates obstacle characteristics.
The boundary of the game field is also taken as an obstacle.
B. Plays
Plays form the second level of our overall hierarchy (first
is Strategy). These represent different situations that can arise
in a game and correspond to the actions that are taken for
them. Reducing the game to a finite number of situations is
not possible. We can however classify situations and undertake
a pre-determined set of actions for them. We have identified
these situations as follows,
GET_GOAL
GET_PASS_GOAL
PENALTY
CORNERKICK_OUR_CORNER
CORNERKICK_THEIR_CORNER
THROW_IN_OUR_HALF
THROW_IN_THEIR_HALF
THEIR_POSSESION_THEIR_HALF
THEIR_POSSESION_OUR_HALF
CLEAR
Every play has its initial weight, the strategy for which it
is applicable and a pre-defined set of tactics that are to
be executed for that play. It also has a maximum time of
completion after which the play will be changed. We also
keep count of the total number of executions of every play, its
successes, failures, aborts and execution times. The number of
successful executions can be used to change the weight of that
play (i.e. the chance that it is chosen again) in the duration of
game play.
C. Strategy
The Strategy module can be likened to the manager of
a football team. It decides the overall nature of the game
by looking at the current ball position, score and the time
23
remaining. Offense, Defense, Penalty etc. are the different
types of strategies. There is a small hysteresis included in the
implementation of the Offense and Defense part. This helps to
avoid rapid switching of strategy as the ball crosses the center
line of the field.
We have used the Epsilon Decreasing Solution to the
Multi Armed Bandit problem to select the current play from
a set of pre-defined plays which are applicable for the current
chosen strategy. It mimics the behavior of a person when faced
with a number of choices with no pre-determined outcomes.
At the initial stages of the game, we choose the plays randomly
from the list of available plays. As the game progresses,
depending upon the strategy of the opponent, some plays give
a lot more successes than others. This leads to an increase in
their relative weight. So it makes sense in the later part of the
game to chose plays that have returned most successes. Hence
we choose only the best applicable play for every strategy in
later stages of the game.
D. Tactic
Each play consists of a set of tactics for every robot. These
have to be performed in the prescribed order for the play to be
a success. An example play with its tactics for 4 teammates
is given below,
PLAY: GET_PASS_GOAL
Robot 1: GET_BALL, PASS, MARK, MARK
Robot 2: MOVE, NONE, RECEIVE_PASS, SHOOT
Robot 3: MARK, MARK, MARK, MARK
Robot 4: MARK, MARK, MARK, MARK
Note that the last 2 robots do not take part in the actual
play. The role of robots does not change in the duration
of the game. To avoid execessively draining the batteries
of forward robots, we change the order of instructions i.e.
GET PASS PASS GOAL will have Robot 3 performing the
shooting task. The routines PASS, SHOOT etc. generate co-
ordinates of the final destination of the robot themselves by
looking at the current world configuration. Every tactic waits
until all the other robots complete their respective tactics of
the previous index. e.g. PASS will wait until MOVE has raised
a completion flag. The whole process can occur as fast as the
execution frequency of the AI structure which is expected to
be around 15 Hz. We do not expect the wait times to be large.
IV. PATH PLANNING
After the strategy selection is done and the robot gets a
command such as goto-point, we need to get an obstacle free
path to the destination. For this purpose we have chosen the
RRT (Rapidly-expanding Random Trees) [3] method due to its
low execution time. Unlike normal path planning methods
which try to optimize every point in the path requiring a lot of
computation, RRT takes a randomized approach to finding the
next point with some bias towards the destination. It is much
faster than other heuristic approaches since it does not need to
explore the region. This is also being used by the CMDragons
team (CMU) for their international RoboSoccer [4] .
 400
300
200
100
00 100 200
Figure 3. RRT with start at (0, 0) and end at (400, 350). Yellow shows the explored tree while the path is marked in red. Black depicts the final smoothened
path of the robot.
A. RRT Algorithm:
1) Get Pnew , the current target, which is a random point
or the final target point depending on a pre-defined
probability.
2) Get Pnear , the point nearest to the new target point
among the points of the current tree.
3) If the distance between Pnew and Pnear is less than
some threshold, an edge joining Pnew to Pnear is added
to the tree. If the distance is greater than the threshold,
extend a branch of a pre-defined length from Pnear
towards the target point Pnew , thus adding a new edge
to the tree. During this step, if it is detected that the new
edge passes through an obstacle, it is not added to the
tree.
4) Repeat 1–3 till the final target point (or some point very
close to it) is reached.
B. Path smoothening
After getting a path from the RRT, we smoothen it so as to
prevent the robot needing a change of direction at every step.
For this, we try to connect the furthest points such that the
300 400 500 600
line segment joining them does not pass through any obstacles.
This works quite well and we get a good straight line path, as
can be seen in Fig. 3, which the robot can follow easily.
V. H ARDWARE
A. Mechanical
The robot drive actuation consists of 2 DC motors in a
differential drive configuration. We targeted a maximum linear
speed of 0.5 m/s with a typical wheel of diameter 50 mm.
This requires the wheel speed of around 190 RPM. Consid-
ering market availability and size constraints, we selected a
perpendicular shaft geared DC motor with no load speed of
220 RPM and a stall torque of 60 mN-m.
The kicker is actuated using a cam-follower mechanism.
The follower is loaded with a spring which impacts the ball
due the step on cam surface as shown in the Fig. 4. This allows
for rapid dispensing of energy from the charging of the spring
with a relatively low power actuator. We have selected a geared
DC motor of 60 RPM as the actuator for the cam, giving us
a reasonable kicker spring charging period of 1 second.
24

R
R
Ball
Figure 4. Kicker and dribbler schematic design
To retain the ball in position before kicking and while
moving with the ball, we use a dribbler which is a rotating
friction cylinder to impart reverse spin to the ball. This cylinder
is actuated by high speed DC motor which is attached to the
kicker itself. This design automatically disengages the ball
from the cylinder when kicked.
B. Electronics
Our design requires 2 bi-directional and 2 uni-directional
motor control. For this purpose, we have used 3 full H-bridge
drivers out of which 2 control the drive motors and the third
controls both the kicker and dribbler. We have selected the
Texas Instruments
R
DRV8801 DC motor driver since it has a
high current capacity of 2.8 A and a small package.
25
The RF link between the computer and the robots is made
with ZigBee
modules using UART interface. The commands
sent from the computer are parsed and executed by a 16-bit
Microchip
dsPIC33FJ32MC804 micro-controller. This is a
powerful micro-controller having a dedicated motor control
module with easy to use PWM generator and a Quadrature
Encoder Interface which can be used in later versions of the
hardware.
VI. C ONCLUSION
This paper gives a brief overview of our system, covering
both the off-board computer software and robot hardware. We
have had to make some compromises in the design of the
system but wherever possible, we have used the experience
gained from our winning entry in the GOAL competition at
TechFest 2009. For example, we have chosen to skip the motor
encoders on the robots which can make controlling them easier
but makes the hardware more complicated. We control the
robots using feedback from only the vision system, which is a
technique we used at the TechFest competition. In this way, we
have chosen to use software as far as possible for controlling
the robots, allowing us to have simpler hardware — which
was one of our main aims during design.
R EFERENCES
[1] B. Browning, J. Bruce, M. Bowling, and M. Veloso,
“STP: Skills, tactics and plays for multi-robot control in
adversarial environments,” IEEE Journal of Control and
Systems Engineering, vol. 219, 2004.
[2] Bret Browing et. al, “CMDragons Code 2002.” http://
www.cs.cmu.edu/∼coral/download/.
[3] S. M. Lavalle, “Rapidly-Exploring Random Trees: A New
Tool for Path Planning,” tech. rep., University of Illinois
Urbana-Champaign, 1998.
[4] J. Bruce and M. Veloso, “Real-Time Randomized Path
Planning for Robot Navigation,” in Proceedings of IROS-
2002, October 2002.
 Introduction to Simulation
League

Without the necessity to maintain any robot hardware, the RoboCup Simulation League's
focus comprises artificial intelligence and team strategy.
Thus, in Simulation League two teams of eleven autonomous software programs (called
agents) each play soccer in a two-dimensional virtual soccer stadium represented by a central
server, called SoccerServer. This server knows everything about the game, i.e. the current
position of all players and the ball, the physics and so on. The game further relies on the
communication between the server and each agent. On the one hand each player receives
relative and noisy input of his virtual sensors (visual, acoustic and physical) and may on the
other hand perform some basic commands (like dashing, turning or kicking) in order to
influence its environment.
The big challenge in the Simulation League is to conclude from all possible world states
(derived from the sensor input by calculating a sight on the world as absolute and noise-free
as possible) to the best possible action to execute. As a game is divided into 6000 cycles this
task has to be accomplished in time slot of 100 ms (the length of each cycle).
This year’s strategies varied from unified approaches like potential field method, to discrete
role switching methods, from using time tested football tactics to modular strategy decision
systems.

*Note: One of the teams from the Simulation league is also participating in SSL League. As
a result only one common paper is published in the SSL section.

26
 Team Description Paper
Nikhil Somani
#
Department of Electrical Engineering,IIT Kharagpur,
Kharagpur, India
1
nikhilsomani.iitkgp@gmail.com
Abstract— Making decisions and switching intelligently between
different player behaviors is an important task in the team
strategy. There are decisions which every player has to make
during each simulation cycle. The salient feature of the strategy
used in this team is the use of potential fields to decide the
optimum move for a robot. For developing these potential fields,
standard soccer strategies like roles(attackers, mid-fielders and
defenders), zone play, distracting opponents, game pace and risk
level(according to score) have been used. Some set moves have
also been developed for penalties, corner-kicks and throw-ins.
Keywords— robosoccer, robocup, simulation league, potential
field, multi-robot, planning, co-operation, co-ordination, soccer
I. INTRODUCTION
Co-ordination and adaptation are the two major challenges
involved in developing robots to work in teams. These
challenges become even more difficult when the environment
involved other agents, particularly adversarial ones which are
not under the team‟s control. In robosoccer, every player has
to take decisions about its move every server cycle. Each
player has 10 team-mates and 11 opponents. This itself
indicates the complexity of the decision-making process. Each
factor that has to be considered before making a decision is
represented as a potential field. A weighted average of these
fields generates a field based on which the player can make
the decision.
II. ROLES OF PLAYERS
The team uses a 3-3-4-1 strategy, i.e, 3 attackers, 3
midfielders, 4 defenders and a goalkeeper.
Fig. 1 The code hierarchy
27
At the first level of hierarchy, the basic player capabilities
like passing to a given team-mate, dribbling in a particular
direction, approaching the ball, leaving the ball, set moves, etc.
are included in the Player class which is inherited by each
player.
At the next level, the strategies specific to the role are
described. These are the Attacker, MidFielder, Defender and
GoalKeeper classes. They describe the strategies which are
common to all players who belong to the corresponding class.
At the next level are the player specific strategies. They
include description of the player zones during normal matches
and set-moves. They also include support for specific set
strategies where the role of each player is clearly defined.
III. POTENTIAL FIELDS
Each factor that a player considers while making a decision
is represented by a potential field. The potential fields are
developed based on the information received from the server.
The information received by each player is relative to itself.
The potential field developed is hence, also relative to the
player. However, some information is fixed and incorporating
it in the potential field requires accurate position and
orientation of the player. Different potential fields used by the
player are described below.
A. Other players
There are several levels of visibility of other players. The
player considers only the players whose teams can be
identified. For a player located at r, ө the potential field
assigns a negative potential cone with peak
(OWN_POTENTIAL) in case of a team-mate and a positive
potential cone with a peak(OPP_POTENTIAL) in case of
opponent in the zone(r – Δr , r + Δr ) and (ө – Δө, ө + Δө).
The values of Δr, Δө, OWN_POTENTIAL and
OPP_POTENTIAL are defined differently for each role. In
case the regions overlap, the potentials are added.
 player should not kick the ball out of the field. Hence, the
parts of the potential field which fall outside the playing area
are given a high positive potential(OUT_POTENTIAL). This
valued is different for different roles of players. This is
because it might be in the interest of a defender to clear the
ball to save a possible goal but is certainly not an option for an
attacker.

Fig. 1 Other Players Potential Field

In the image described above, the yellow quadrant indicates

the player under consideration. The blue area indicates the
field around a team-mate. The black area indicates the field
around an opponent.
Fig. 4 Kick Power Potential Field
B. Ball potential
The ball is considered to be in possession of the player if it
is within the kicking distance. In case the player possesses the E. Play Direction Potential
ball, In case the player does not possess the ball, the “Other This potential determines the direction in which the ball
players” potential field is reversed, i.e, the team-mates are progresses. The potential field is slanted down towards the
assigned positive potentials and opponents negative potentials. opponent goal-post. The gradient(FIELD_GRADIENT)
depends upon the player role. For example, a defender should
always look to play the ball forward towards the opponent
goal. The mid-fielders should be less strict about the direction
C. Goal Potential
of the ball passing and should pass it around amongst
This is an absolute field. The opponent goal is given a very themselves till they find an opening. The attackers should look
high negative potential(OPP_GOAL) and the own goal is to score but might also require to pass it back in case the
given a very high positive potential(OWN_GOAL). Again, attack fails.
the values of these potentials depend upon the role of the
player. This field requires the accurate location and
orientation of the player so that the absolute field can be
converted to a relative field.

Fig. 5 Play Direction Potential Field

Fig. 3 Goal Potential Field

In the figure given above, the opponent goal is on the right.
D. Kicking Power Potential The potential can be seen to decrease as we move from left to
The kicking power of a player is limited. Hence, the right.
potential increases with the distance from the player. Also, the

28
F. Zone Potential
The players are assigned zones of play. They are expected
to stick to their zones. If they reach the boundary of their
zones and possess the ball, they should look to pass it. The
potential rises beyond the zone boundaries.
Conclusions
An important advantage of using these potential fields is that
the weights of each of the parameters used to generate a field
can be adjusted dynamically to enable higher levels of team
planning such as pace and risk level of the game depending
upon the score, stamina and other factors.

REFERENCES
[1] Michael Bowling, Brett Browning, Allen Chang and Manuela Veloso,
“Plays as team plans for co-ordination and adaptation”, Computer
Science Department, Carnegie Mellon University, Pittsburgh PA,
15213-3891, USA.
[2] Peter Cogill, “The university of Queensland CrocaRoos : A planning
system for the simulation league”, University of Queensland.
[3] Ashley Tews, Gordon Wyeth, “MAPS : a system for multi-agent co-
ordination”, Computer Science and Electrical Engineering, University
of Queensland, Brisbane, Queensland 4072, Australia
[4] Jun Akiyama, “Adapting the multi-agent planning system for Robocup
Simulation League”, Department of Information Technology and
Fig. 6 Zone Potential Field Electrical Engineering, University of Queensland.

In the figure given above, the green rectangles represent the

zones of the defenders(the central zone is for common for the
2 centre defenders), the orange rectangles represent the zones
of the mid-fielders and the red rectangles represent the zones
of the attackers.

IV. GAME STRATEGIES

For each player, the potential fields are updated regularly.
The combination of these potential fields generates a final
field which is used to decide the action to be taken.
For a player having possession of the ball, the zone
potential field is subtracted from the combined field. The
possible options are kicking the ball / passing and dribbling. If
a trough exists in the field and a path with sufficiently low
potential leading to it exists, the ball is kicked in that direction
with calculated power such that it just reaches the trough.
If a path does not exist, the zone potential field is again
added to the combined field. The player dribbles in the
direction of least potential in a small radius in this modified
field.
If the player does not possess the ball, it simply dashes
towards the point of least potential in the field.
The values of the potential field constants can be changed
to change the nature and pace of the game. There are some
standard modes like „defensive‟, „attacking‟, „normal‟, „time
wasting‟. Each mode has a different set of values of these
constants. Depending upon the score, time elapsed and
stamina of the players, the game mode can be made to switch.

29
 Team Description: RoboCup Challenge ‘09
Strategies for Coordination among Soccer-Bots in a
Simulated Multi-Agent Environment
Rasha Eqbal
Department of Computer Science and Engineering, Indian Institute of Technology - Kharagpur
Kharagpur, India
rasha.eq@gmail.com
Abstract— This document gives an overview of strategies used by
robots working as a team in RoboSoccer Simulation. The
approach taken involves simple decision making and action
selection based on these decisions.
Keywords— RoboSoccer, decision making, localisation, hovering,
dribble, pass, kick, goalkeeper
I. INTRODUCTION
This paper describes a simple algorithm to decide which
action is most favourable for a player and his team at any
given point of time. This decision is made based on several
input parameters: like position of the player on the field;
distance of the player from the ball, from the goal and from
other players in his field of view; angular displacement of the
player’s line of sight from the ball, the goal and the other
players in his vicinity. The player then takes a course of action
depending on these external inputs and the role allotted to him
as part of the team.
II. LOCALISATION OF PLAYERS
The players’ location on the field can be estimated with the
aid of stationary flags placed along the boundary of the field.
At any point of time a player knows his distance and
orientation with respect to at least three such flags on the
boundary. If he is at a distance d from a flag, he knows that
his position is anywhere on the circumference of a circle of
radius d centred at the concerned flag. He concludes this about
three different flags and hence three different circles. Thus his
position is simply at the intersection point of these three
circles. As there can be only one such point, the position of
the player on the field can be accurately calculated.
III. HOVERING OF PLAYERS ON THE FIELD
The players of a team are assigned different roles. Three
players take on the role of Attackers, four Mid-Fielders, three
Defenders and one Goalkeeper. Based on the roles assigned to
them, the players are allotted zones on the field they are
expected to restrict themselves to, so that they are in a
30
favourable position to carry out their assigned role effectively.
This also ensures an even distribution of players on the field at
any time, thereby causing less hindrance in the actions of
teammates. To implement this, all that needs to be done is
make the players move towards their assigned zones when
they are involved in no other concrete action, like dribbling
the ball, passing it or kicking it. When in their respective
regions the players try to look around for the ball simply by
turning on the spot and moving within the confined area. Once
the ball is located they try to keep it within sight.
IV. LOCATING THE BALL
All the players in their assigned zones try to look for the
ball, moving only within their zone boundaries. Once they
locate the ball, they face in its direction and try not to lose
sight of it. When the distance of the ball from a player is less
than a certain threshold, only then does he try to move
towards it. This ensures unnecessary clustering of players
around the ball.
V. ACTION AFTER LOCATING THE BALL
Once a player has oriented himself in the direction of the
ball, his next course of action is decided depending upon his
position with respect to the ball, the goal, and other teammates
and opponents in his vicinity. The various decisions and the
corresponding actions he can select from are:
A. Move towards the Ball
The player will try to locate the nearest teammate, and will
decide if he himself should move towards the ball or let his
teammate get it. The player has information about his distance
and orientation from the ball, and also his distance from and
orientation with respect to the teammates in his vicinity. From
this data, he can calculate the distances from the ball of the
teammates around him. If he finds that another teammate is
closer to the ball, he will not move towards it, giving the other
closer teammate a better chance to get the ball, while he
himself continues to track the position of the ball. If no
teammate around him is closer than him to the ball, he will implemented by all the players except the goalkeeper, whose
move towards the ball himself. sole task is to defend the goal.

B. Dribble the Ball TABLE I

DECISION MAKING: CONFIGURATION OF ENVIRONMENT AND CORRESPONDING
This course of action is taken when a player has the ball COURSE OF ACTION FOLLOWED
and sees that he is not in a favourable position to kick the ball
towards the goal. This might happen in two cases: Configuration Action
1. Player’s distance from the ball below a Move
1) When a player finds himself surrounded by opponents: threshold towards the
No other teammate closer to the ball ball
The player checks to see if the number of opponents
around him is more than his surrounding teammates. If 2. Player has the ball Dribble the
this be the case, it might not be favourable to pass the Too far away from the goal and no ball towards
ball to a teammate or to kick it towards the goal. So he teammate in sight the goal
dribbles the ball, trying to move away from the 3. Player has the ball Dribble the
opponents. More surrounded by opponents than ball away
teammates in the vicinity from
2) When the goal is too far away and no teammate is in opponents
sight: The player checks to see if his distance from the 4. Player has the ball Pass the
goal is below a certain threshold value. If it is, only Teammate closer to the goal ball to
then does he kick the ball towards the goal. Also if no teammate
5. Player has the ball Kick the ball
teammate can be found in his immediate vicinity so
Player close enough to the goal towards the
that he can pass the ball, he dribbles it, moving in the goal
direction of the goal. 6. Player has the ball Kick the ball
No teammate closer to the goal towards the
Not surrounded more by opponents than by goal
C. Pass the Ball teammates
This course of action is taken when a player has the ball 7. Player does not have the ball Locate the
and sees that he is not in a favourable position to kick the ball, Player in assigned zone ball
but another teammate is. The player first checks to see if he is Player not turned towards the ball
8. Player does not have the ball Keep track
close enough to the goal to attempt a kick. If not, he looks
Player in assigned zone of the ball’s
around for another teammate who might be closer to the goal. Player turned towards the ball location
If he does find such a player, he passes on the ball to him. 9. Player not in assigned zone Move
Otherwise he simply continues dribbling the ball in the towards the
direction of the goal. assigned
zone

D. Kick the Ball

The player first checks all the above cases to decide
whether he should kick or not. If he is close enough to the
goal i.e. his distance from the goal is below a certain threshold
OR no other teammate is closer to the goal than him, he kicks
the ball in the direction of the goal.
VI. GOALKEEPER ACTION
The goalkeeper hovers around the goal in his zone, keeping
track of the ball all the time. As soon as he finds the distance
between him and the ball below a certain threshold, he moves
towards the ball and kicks it away from the goal.
VII. SUMMARY OF THE DECISION MAKING PROCEDURE
DISCUSSED
This section outlines the basic steps involved in decision
making in a neat tabular form. The steps given are
VIII. CONCLUSION
The basic algorithm outlined in this document was the
selection of actions based on evaluation of various input
parameters. The robots use information received from the
environment, process it, and then decide on the most favorable
course of action to be adopted. The simple logic discussed is
somewhat similar to the reasoning adopted in a real world
situation.
REFERENCES
[1] Shuhei Kinoshita and Yoshikazu Yamamoto, Team 11 Monkeys
Description, RoboCup-99 Team Descriptions.
[2] Peter Stone, Manuela Veloso, and Patrick Riley, CMUnited-98:
RoboCup-98 Simulator World Champion Team, July 24, 1999.
[3] Luiz Antonio Celiberto Junior and Reinaldo A. C. Bianchi, FEISIM’06:
FEI Reinforcement Learning RoboCup 2D Soccer Simulation Team.

31
[4] Amin Milani Fard, M. Hossein Ansari, Armin Ildermi, Sina
Molavipour, Mahdi Aledaghi, Farid Seifi and Mahmoud Naghibzadeh,
Nexus 2D 2008 Team Description.
[5] Simon Ch’ng and Lin Padgham, Team Description: Building Teams
Using Roles, Responsibilities, and Strategies.
[6] R. Geetha Ramani, Dr. R. Subramanian and M. Sindurathy, Strategies
of Teams in Soccerbots.
[7] Hatice Kose, Kemal Kaplan, Cetin Mericli, Utku Tatlidede and Levent
Akin, Market-Driven Multi-Agent Collaboration in Robot Soccer
Domain.

32
 Team Description: Robocup Challenge ’09
United 11
Dheeraj Kumar Singh
Department of Computer Science and Engineering, IIT Kharagpur
D-101, Patel Hall of Residence, IIT Kharagpur, India

Abstract— In this paper we introduce ‘Task Division’ between

the various agents to achieve the common goal. The team is
divided into three main groups of players who have different
roles to play according to their position on the field and the state
of the game. We concentrate on achieving the goal with
minimum communication between the agents. A set of ‘basic
tasks’ have been identified which enhance the efficiency of the
agents. These tasks include passing, interception, gap creation
and dribbling among others. The objective is to work on and
improve the abilities of the agents to perform these basic actions
with more effectiveness. The agents need to communicate only to
force a particular action on another agent.

I. INTRODUCTION
The main purpose of the paper was to analyse the effect of
“Task Division” in a multi-agent environment. The work here
has been divided into three categories. Apart from this each Fig. 1 An example of division of regions on the playing field. The regions
agent is also confined to his region on the field which he does marked are dynamic in nature depending on the position of the opponent
not leave except in situations which need him to leave it. players and the position of the ball

II. DIVISION OF TASK B. Calculation of Approximate Position

The task as mentioned is divided into three main categories.
As is intuitively obvious we have the attackers, mid-fielders
and the defenders. To make this possible various aspects need
to be taken care of such as the placement of the agents on the
field.
A. Division of Field into Regions
The field is divided in various regions and the agents are
assigned to a specific region. The exact division of the field
will depend on the game position. An instance of division of
field is shown in the figure below. The division is not a static
division and it is affected by various factors.
The division of regions on the field requires the agents to
approximate their positions. The agents approximate their
position on the field using objects and their locations with
respect to them. If the agent knows his distance from three
different flags the intersection of three circles can be
calculated to find out the position of the agent. In case the
three flags are not visible at a given point of the time the agent
uses his previous position to approximate his current position.

Fig. 2 The intersection of the circles of the three flags gives the position of the
agent

33
C. Different Roles B. Gap creation
If there is no division of roles the agents will tend to play The supporting players will tend to move so as to increase
selfishly. The players will first have a static role that is the interception angle to make it easier for the player with the
defined to them on a “Strategy Level”. Then on an “Individual ball to pass.
Level” the players will have dynamic roles defined to them.
The roles that are defined on the “Strategy Level” are static
because this role will not change in the course of the game.
An attacker will always have a tendency to aim towards the
goal rather than passing. The mid-fielders will tend to pass the
ball among them till one of the attackers is free to accept a
pass. The defenders will tend to pass the ball forward, they
will also have a tendency to kick the ball forward in a random
direction if their possession of the ball is threatened.

On an “Individual Level” the players will have different

roles depending on whether they are in possession of the ball,
or they are the person closest to the ball apart from the agent
in possession of the ball. Or if they are the agent trying to
block an opponent player.

III. BASIC TASKS

A set of basic tasks have been identified that help the agent Fig. 3 The motion of the agents is shown with the arrows. The agents A2 and
A3 will tend to move so that the interception angles X1 and X2 increase
perform his role better. These tasks remain the same for all the
agents. However the selection from these tasks will differ for
the different agents.
C. Dribbling
A. Passing Dribbling consists of kicking the ball forward with a small
The agents will tend to choose the agent who is least likely to force and then following the ball. The force of the kick will be
be intercepted while deciding who to pass the ball to. To inversely proportional to the distance of the closest opposing
estimate this, the agents will use the view that is free and the player near the player that is dribbling and in the direction of
distance of the other agent from them. the dribble.
D. Interception
Depending on the previous direction and position of the
ball the player can estimate the speed and direction of the ball.
Interception then is kicking the ball in the opposite direction
with a force proportional to the speed of the ball.

Fig. 3The red dot represents the opponent players and the
blue dots the players of the same team. Here A1had the ball,
he would have selected to pass it to A3 and not A2 as the
interception angle X1 is more than X2
Fig. 5 The velocity of the ball can be computed as the ratio
of the vector difference between the current and previous
ball position and the difference in time cycles

34

IV. DECISION MAKING
The decision making for the agents can be divided into two
stages. In the first stage the agents based on their individual
skill decide for each possible action which is the best course.
For example of a player has the ball he will decide for each
possible action, ie. Passing, dribbling and shooting which
among them in each of them is the best way of doing it. In the
second stage based on its static role and the best actions
decided the agent chooses which action is the best one.
V. CONCLUSIONS AND FUTURE WORK
The research done here has relied more on static strategies
which makes the algorithm rigid. The work has also relied
more on the individual skill of the players and information
exchange between the players is minimum. Future work can
be done more on coordination and information exchange.
35
REFERENCES
[1] Nexus 2D 2008 Team Description, Amin Milani Fard, M. Hossein
Ansari, Armin Ildermi, Sina Molavipour, Mahdi Aledaghi,Farid Seifi,
Mahmoud Naghibzadeh ,Software Simulation and Modeling
Laboratory, Department of Computer Engineering, Ferdowsi
University of Mashhad, Mashhad, Iran, nexus@um.ac.ir,
http://nexus.um.ac.ir
[2] Robocup – 99 Team Description , Simulation League, Team 11
monkeys, http://www.ep.liu.se/ea/cis/1999/007/34, Shuhei Kinoshita,
Yoshikazu Yamamoto
[3] CMUnited98: RoboCup98, Simulator World Champion Team, Peter
Stone, Manuela Veloso, and Patrick Riley, Computer Science
Department,Carnegie Mellon University, Pittsburgh, PA 15213
[4] OxBlue2008(2D) Team Description, Jie Ma and Stephen Cameron,
Oxford University Computing Laboratory, Wolfson Building, Parks
Road, Oxford, OX1 3QD, UK,
{jie.ma,stephen.cameron}@comlab.ox.ac.uk,
http://www.comlab.ox.ac.uk
Acknowledgements
We express our acknowledgements to the following respected committee members for
patiently reviewing and approving the work.

 Professor Jayanta Mukhopadhyay

Department of Computer Science and Engineering
General Co - Chair
 Professor Dilip Kumar Pratihar
Department of Mechanical Engineering
General Co - Chair
 Professor Sudeshna Sarkar
Department of Computer Science and Engineering
Organizing Co - Chair
 Professor Gaurav Harit
Department of Computer Science and Engineering
Organizing Co - Chair

We would also like to extend a word of thanks to our generous sponsors for their
encouragement and support.

Union Bank of India

Goal.com

IEEE Kharagpur Section

36