team description paper
TRANSCRIPT
Proceedings of
RoboCup Challenge @ India 2009
IIT Kharagpur
Editors :
Kaustubh Tripathi
(Department of Computer Science
and Engineering)
Sanjiban Choudhury
(Department of Electrical
Engineering)
1
“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.”
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 :
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
[email protected] [email protected]
[email protected] [email protected]
[email protected] [email protected]
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.
I. INTRODUCTION
KGPTigers is IIT Kharagpur’s first ever entry into the RoboCup SSL league. The work that went behind this entry was to develop the whole platform to control multiple agents and engage them in the game of soccer. The paper is divided into the following sections – the vision system, the hardware system and the intelligence architecture. Along the way, we also discuss the problems faced and the solutions arrived at. The paper concludes with prospects for future developments.
II. VISION 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
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.
The central marker is reserved for the team colour markers i.e. blue or yellow. There is also a header marker that has a unique colour on the bot, which determines the angle of the robot. There are also other identification markers of a different colour. The number of these identification markers, along with the header marker uniquely identifies the robot.
III. ROBOT HARDWARE
The robots used are MIROSOT-100 robots which formed the basic platform on which we built around.
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.
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.
7
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
����� = ������� �
(1) Since the robot is a differential drive, it is better modelled by extended Kalman filters since its motion is non-linear. The state space model for the robot is
�� � � = �������
(2) The filters have several advantages –
1. Given a time stamp, the postion of the ball and the bot can be predicted.
2. The filter can be tuned to converge faster at the same time tolerating greater error by increasing the process noise.
3. Occlusions may occur in the image processing where certain frames may miss the robot, which can be handled by the Kalman filter.
B. Real time path planning The path planning is treated as a black box module whose input is the initial and final configuration and output is expected to be the series of intermediate states to reach the configuration respecting constraints. The condition also demands that the module be a “hard real time system”; failure to output the path within a given interval T would mean complete failure. Other issues are state discretizations, efficiency v/s accuracy trade-off and respecting kinematical constraints. We adopt the method of RRT [3] (Rapidly-exploring Random Trees) as a basis for out path planning. The ingenuity of the method lies in the fact that it doesn’t delve into state discretization and thus prevents the explosion of nodes with
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, nearest,target); if (extended != EmptyState) then
AddNode (tree, extended);
return tree;
function ChooseTarget(goal:state):state var p:real; var i:integer; p = UniformRandom in [0.0 .. 1.0]; i = UniformRandom in [0 .. NumWayPoints-1]; if (0 < p < GoalProb) then
return goal; else if (GoalProb < p < GoalProb+WayPointProb) then
return WayPointCache[i]; else if (GoalProb+WayPointProb < p < 1) then
return RandomState(); function Nearest (tree:rrt-tree,target:state):state
var nearest:state; nearest := EmptyState; for each state s in current-tree
if (Distance (s,target) < Distance (nearest,target)) then
nearest := s; return nearest;
Table x: The outlay of the ERRT approach to path planning. This algorithm was primarily meant for omni-directional robots which have less constraints than the differential drives that we used. Hence, the following improvements were applied by us – 1) Generated path must be smooth –
Differential drives have a limitation in their
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:
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
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
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;
9
Send ‘go to’ command and coordinates to robot
end 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.
(iii) Robot Influence Field: It makes a small region around the robots repulsive or attractive depending on the situation. Say, we require a attractive field around the teammates when trying to pass the ball and a repulsive region in order to avoid crowding.
(iv) Clear Path to Ball Field: It makes a region repulsive where it is not possible to kick the ball to, like the regions behind the robots from the point of view of the ball.
(v) Clear Path to Goal Field: It makes a region repulsive from where the view of the goal is obstructed. This helps the players to go to a better position to receive the ball and shoot.
2) MAPS Command Fields:
(i) Kick To Field: All the above fields except the last are built and added together. The point corresponding to the lowest value is 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.
Defending in extreme situations: When an opponent is very close to our goal, the closest teammate goes for the ball and others get in the way of the attacker and the goal to prevent a goal from being conceded.
Figure 7. The potential field
Above is a snapshot of the simulator showing an attacking go to field for blue robot lowest in the picture. This field did not add the Clear Path To Goal Field. The black circle represents the point returned to this robot by MAPS to go to. Potential and thus repulsiveness decreases from darker to lighter regions. D. Differential drive control for position We use a set of reactive equations for robot control [6]. If we want our drive to turn from �to � then let ∆ = � − � (1) #$, &' = #()* ∆ ∗ *+,#cos#∆'' , *0, ∆ ∗ *+,#sin#∆''' (2) �� = �#$ + &' (3) �� = �#$ − &' (4) The above set of equations bound any wheel’s speed by �.
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. [email protected] [email protected]
[email protected] [email protected] [email protected]
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.
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. 1 CAD of IRL RC Omni Directional Bot
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. 4 IRL RC Dribbling Mechanism
III. ELECTRICAL SYSTEM
The central controller consists of one ATMega16 and one ATMega8 microcontrollers. ATMega16 communicates with the Maxstream XBee Seies 2 modules at a baud rate of 9600 bps. These modules are low power RF devices which work on Zigbee protocol. Each of the RF devices is embedded in each bot and they communicate with the XBee module connected to the Decision System. The command from the Decision system to the bot contains the information about the speed of each wheel, dibbling on/off and kicking on/off.
ATMega8 generates required signals for the dribbling and kicking. It acts a slave to the main controller – ATMega16.
The stepper motors are driven by L298-L297 pairs. The driver circuit for the stepper motor consists of four L298-L297 pairs connected to ATMega16. The servo motor and the dribbler roller motor are driven by one L293D connected to ATMega8.
Our custom made double layered PCBs for the central controller and the driver circuits are given in Fig. 5 and Fig. 6 respectively.
The whole electrical system is driven by a 11.1 V, 2200 mAh Li-Po battery. To cool the electrical system we use a
CPU fan which consists of 12V DC brushless motor.
Fig. 5 IRL RC Central Controller
Fig. 6 IRL RC Motor Driver Circuit
IV. SOFTWARE SYSTEM
Our software system is divided into two different entities;
one is Vision System and the other one is Decision System. They communicate with each other using UDP through socket programming. Their descriptions are given below.
A. Vision System
We are using Unibrain Fire-I firewire digital camera ( IEE 1394 ) which supports 30 fps in the mode YUV 4:1:1 with a resolution of 640 X 480.
We are using openCV open source library for all the vision process. Our algorithm first finds the centers of the robots and the ball in a frame using thresholds in YUV space discarding the Y channel to compensate the effects caused by the illumination changes. We have used our own extension of the algorithm described in [1] which can determine the ids of the robots and their orientations robustly.
This system sends the bots’ positions, their orientations and the ball’s position to the Decision System in a UDP using socket programming in Linux. We’ve chosen UDP because it is connectionless and it does not do error correction and flow 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.
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.
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/product-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
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.
[email protected] [email protected]
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.
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.
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
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
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.
17
=> 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
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.
19
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
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.
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”.
20
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 DescriptionKartik Mohta, Pratik Chaudhari, Simit Pradhan,
Siraj Issani, Vishal Prabhu
Abstract—This paper describes FootBots, our entry for theSmall Size League Robosoccer at RoboCup Challenge India 2009.
I. INTRODUCTION
Our team entry consists of multiple differential drive robotscontrolled by an off-board computer. The sensing is providedby two cameras mounted over the arena. The software takesthe images from the cameras, calculates the robot commandsand sends them to the individual robots.
II. VISION
We use the OpenCV library for image processing. Inputis taken as a video stream from the two cameras in orderto cover the whole arena and the frames are merged. Theseframes are processed to get the positions of the robots andthe ball on the field. RGB images are first converted to theHSV colour-space in order to make the detections more robustagainst variations in the lighting conditions. Segmentation ofthe image is done using pre-defined ranges for colors in theblobslib module of OpenCV. This results in blobs of differentcolors corresponding to the colors of the robots on a blackbackground which is the field. The final step is to convertthe pixel values accurately to actual distances for which wecalibrate the camera before hand. Note that this is the onlysource of robot position in the current implementation.
Camera 1 Camera 2
Merge
HSV Conversion
Colour Filtering
Blob Detection
Output
Figure 1. Image processing pipeline
III. STRATEGY
Strategy selection cannot be a set of pre-defined rules dueto nature of this problem. We have used a hierarchical systemthat generates overall strategies as well as individual robotcommands for these strategies. It is based upon the STPstructure as described in Browning et. al. [1,2]. Note that thefollowing section only deals with the strategies used for theplaying robots i.e. excluding the goal-keeper, the strategyfor which is separately evaluated by looking at the currentpositions of the robots and the ball. This is done so to simplifythe strategy. It handicaps the defence however in the sense thatthere is no relation between the movements of the defencerobots and the goalie.
Camera
Vision
World
Strategy Plays Tactics
Robot
Figure 2. Strategy hierarchy
A. World
As mentioned earlier, the Vision module is responsible forgenerating the positions of all the objects on the field. Thisincludes the ball, the opponent robots, and the team robots. Fortaking decisions regarding the strategy, we would ideally needthe velocities and positions of all the entities on the playingfield. However, extracting the velocity of the opponent robotsis a difficult task (without identifying them individually). Ifwe decide to track a particular blob to get the velocity, small
[email protected], Bangalore - 560 008
22
incidents like occlusion or mis-detection of the same blob inconsecutive frames can cause huge errors in the perceivedvelocity. Hence, in the current implementation we rely onlyupon the knowledge of the positions of all the opponents.
The strategy part of course knows the velocities assignedto each team robot and its current direction. These velocitiesare used in the decision making process. Thus the positions ofobjects from the vision module and commanded velocities ofteammates along with their commanded orientations togetherform the input to the world. It is the job of this module to keeptrack of all these these things along with their time stamps tobe 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 positionsare stored in the world co-ordinate frame. We can convert theseco-ordinates to robot specific coordinates to aid in calculationsof the form nearest-opponent or nearest teammate for a robot.The path planning module takes input in the form of obstaclepositions, source position and destination position. This hasto be generated by considering the current positions of therobots. 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 (firstis Strategy). These represent different situations that can arisein a game and correspond to the actions that are taken forthem. Reducing the game to a finite number of situations isnot possible. We can however classify situations and undertakea pre-determined set of actions for them. We have identifiedthese situations as follows,
GET_GOALGET_PASS_GOALPENALTYCORNERKICK_OUR_CORNERCORNERKICK_THEIR_CORNERTHROW_IN_OUR_HALFTHROW_IN_THEIR_HALFTHEIR_POSSESION_THEIR_HALFTHEIR_POSSESION_OUR_HALFCLEAR
Every play has its initial weight, the strategy for which itis applicable and a pre-defined set of tactics that are tobe executed for that play. It also has a maximum time ofcompletion after which the play will be changed. We alsokeep count of the total number of executions of every play, itssuccesses, failures, aborts and execution times. The number ofsuccessful executions can be used to change the weight of thatplay (i.e. the chance that it is chosen again) in the duration ofgame play.
C. Strategy
The Strategy module can be likened to the manager ofa football team. It decides the overall nature of the gameby looking at the current ball position, score and the time
remaining. Offense, Defense, Penalty etc. are the differenttypes of strategies. There is a small hysteresis included in theimplementation of the Offense and Defense part. This helps toavoid rapid switching of strategy as the ball crosses the centerline of the field.
We have used the Epsilon Decreasing Solution to theMulti Armed Bandit problem to select the current play froma set of pre-defined plays which are applicable for the currentchosen strategy. It mimics the behavior of a person when facedwith a number of choices with no pre-determined outcomes.At the initial stages of the game, we choose the plays randomlyfrom the list of available plays. As the game progresses,depending upon the strategy of the opponent, some plays givea lot more successes than others. This leads to an increase intheir relative weight. So it makes sense in the later part of thegame to chose plays that have returned most successes. Hencewe choose only the best applicable play for every strategy inlater stages of the game.
D. Tactic
Each play consists of a set of tactics for every robot. Thesehave to be performed in the prescribed order for the play to bea success. An example play with its tactics for 4 teammatesis given below,
PLAY: GET_PASS_GOAL
Robot 1: GET_BALL, PASS, MARK, MARKRobot 2: MOVE, NONE, RECEIVE_PASS, SHOOTRobot 3: MARK, MARK, MARK, MARKRobot 4: MARK, MARK, MARK, MARK
Note that the last 2 robots do not take part in the actualplay. The role of robots does not change in the durationof the game. To avoid execessively draining the batteriesof forward robots, we change the order of instructions i.e.GET PASS PASS GOAL will have Robot 3 performing theshooting task. The routines PASS, SHOOT etc. generate co-ordinates of the final destination of the robot themselves bylooking at the current world configuration. Every tactic waitsuntil all the other robots complete their respective tactics ofthe previous index. e.g. PASS will wait until MOVE has raiseda completion flag. The whole process can occur as fast as theexecution frequency of the AI structure which is expected tobe 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 acommand such as goto-point, we need to get an obstacle freepath to the destination. For this purpose we have chosen theRRT (Rapidly-expanding Random Trees) [3] method due to itslow execution time. Unlike normal path planning methodswhich try to optimize every point in the path requiring a lot ofcomputation, RRT takes a randomized approach to finding thenext point with some bias towards the destination. It is muchfaster than other heuristic approaches since it does not need toexplore the region. This is also being used by the CMDragonsteam (CMU) for their international RoboSoccer [4].
23
0 100 200 300 400 500 6000
100
200
300
400
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 smoothenedpath of the robot.
A. RRT Algorithm:
1) Get Pnew, the current target, which is a random pointor the final target point depending on a pre-definedprobability.
2) Get Pnear, the point nearest to the new target pointamong the points of the current tree.
3) If the distance between Pnew and Pnear is less thansome threshold, an edge joining Pnew to Pnear is addedto 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 edgeto the tree. During this step, if it is detected that the newedge passes through an obstacle, it is not added to thetree.
4) Repeat 1–3 till the final target point (or some point veryclose to it) is reached.
B. Path smoothening
After getting a path from the RRT, we smoothen it so as toprevent the robot needing a change of direction at every step.For this, we try to connect the furthest points such that the
line segment joining them does not pass through any obstacles.This works quite well and we get a good straight line path, ascan be seen in Fig. 3, which the robot can follow easily.
V. HARDWARE
A. Mechanical
The robot drive actuation consists of 2 DC motors in adifferential drive configuration. We targeted a maximum linearspeed 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 aperpendicular shaft geared DC motor with no load speed of220 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 balldue the step on cam surface as shown in the Fig. 4. This allowsfor rapid dispensing of energy from the charging of the springwith a relatively low power actuator. We have selected a gearedDC motor of 60 RPM as the actuator for the cam, giving usa reasonable kicker spring charging period of 1 second.
24
Ball
Figure 4. Kicker and dribbler schematic design
To retain the ball in position before kicking and whilemoving with the ball, we use a dribbler which is a rotatingfriction cylinder to impart reverse spin to the ball. This cylinderis actuated by high speed DC motor which is attached to thekicker itself. This design automatically disengages the ballfrom the cylinder when kicked.
B. Electronics
Our design requires 2 bi-directional and 2 uni-directionalmotor control. For this purpose, we have used 3 full H-bridgedrivers out of which 2 control the drive motors and the thirdcontrols both the kicker and dribbler. We have selected theTexas Instruments R© DRV8801 DC motor driver since it has ahigh current capacity of 2.8 A and a small package.
The RF link between the computer and the robots is madewith ZigBee R© modules using UART interface. The commandssent from the computer are parsed and executed by a 16-bitMicrochip R© dsPIC33FJ32MC804 micro-controller. This is apowerful micro-controller having a dedicated motor controlmodule with easy to use PWM generator and a QuadratureEncoder Interface which can be used in later versions of thehardware.
VI. CONCLUSION
This paper gives a brief overview of our system, coveringboth the off-board computer software and robot hardware. Wehave had to make some compromises in the design of thesystem but wherever possible, we have used the experiencegained from our winning entry in the GOAL competition atTechFest 2009. For example, we have chosen to skip the motorencoders on the robots which can make controlling them easierbut makes the hardware more complicated. We control therobots using feedback from only the vision system, which is atechnique we used at the TechFest competition. In this way, wehave chosen to use software as far as possible for controllingthe robots, allowing us to have simpler hardware — whichwas one of our main aims during design.
REFERENCES
[1] B. Browning, J. Bruce, M. Bowling, and M. Veloso,“STP: Skills, tactics and plays for multi-robot control inadversarial environments,” IEEE Journal of Control andSystems 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 NewTool for Path Planning,” tech. rep., University of IllinoisUrbana-Champaign, 1998.
[4] J. Bruce and M. Veloso, “Real-Time Randomized PathPlanning for Robot Navigation,” in Proceedings of IROS-2002, October 2002.
25
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 [email protected]
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
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.
27
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.
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
ball, In case the player does not possess the ball, the “Other
players” potential field is reversed, i.e, the team-mates are
assigned positive potentials and opponents negative potentials.
C. Goal Potential
This is an absolute field. The opponent goal is given a very
high negative potential(OPP_GOAL) and the own goal is
given a very high positive potential(OWN_GOAL). Again,
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. 3 Goal Potential Field
D. Kicking Power Potential
The kicking power of a player is limited. Hence, the
potential increases with the distance from the player. Also, the
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. 4 Kick Power Potential Field
E. Play Direction Potential
This potential determines the direction in which the ball
progresses. The potential field is slanted down towards the
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
of the ball passing and should pass it around amongst
themselves till they find an opening. The attackers should look
to score but might also require to pass it back in case the
attack fails.
Fig. 5 Play Direction Potential Field
In the figure given above, the opponent goal is on the right.
The potential can be seen to decrease as we move from left to
right.
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.
Fig. 6 Zone Potential Field
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.
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 Electrical Engineering, University of Queensland.
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
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
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
30
teammate around him is closer than him to the ball, he will
move towards the ball himself.
B. Dribble the Ball
This course of action is taken when a player has the ball
and sees that he is not in a favourable position to kick the ball
towards the goal. This might happen in two cases:
1) When a player finds himself surrounded by opponents:
The player checks to see if the number of opponents
around him is more than his surrounding teammates. If
this be the case, it might not be favourable to pass the
ball to a teammate or to kick it towards the goal. So he
dribbles the ball, trying to move away from the
opponents.
2) When the goal is too far away and no teammate is in
sight: The player checks to see if his distance from the
goal is below a certain threshold value. If it is, only then does he kick the ball towards the goal. Also if no
teammate can be found in his immediate vicinity so
that he can pass the ball, he dribbles it, moving in the
direction of the goal.
C. Pass the Ball
This course of action is taken when a player has the ball
and sees that he is not in a favourable position to kick the ball,
but another teammate is. The player first checks to see if he is
close enough to the goal to attempt a kick. If not, he looks
around for another teammate who might be closer to the goal.
If he does find such a player, he passes on the ball to him.
Otherwise he simply continues dribbling the ball in the
direction of the goal.
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
implemented by all the players except the goalkeeper, whose
sole task is to defend the goal.
TABLE I
DECISION MAKING: CONFIGURATION OF ENVIRONMENT AND CORRESPONDING
COURSE OF ACTION FOLLOWED
Configuration Action
1. Player’s distance from the ball below a threshold No other teammate closer to the ball
Move towards the ball
2. Player has the ball Too far away from the goal and no
teammate in sight
Dribble the ball towards
the goal
3. Player has the ball More surrounded by opponents than teammates in the vicinity
Dribble the ball away from opponents
4. Player has the ball
Teammate closer to the goal
Pass the
ball to teammate
5. Player has the ball Player close enough to the goal
Kick the ball towards the goal
6. Player has the ball No teammate closer to the goal
Not surrounded more by opponents than by teammates
Kick the ball towards the
goal
7. Player does not have the ball Player in assigned zone Player not turned towards the ball
Locate the ball
8. Player does not have the ball Player in assigned zone
Player turned towards the ball
Keep track of the ball’s
location
9. Player not in assigned zone Move towards the assigned zone
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
agent is also confined to his region on the field which he does
not leave except in situations which need him to leave it.
II. DIVISION OF TASK
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.
Fig. 1 An example of division of regions on the playing field. The regions
marked are dynamic in nature depending on the position of the opponent players and the position of the ball
B. Calculation of Approximate Position
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
If there is no division of roles the agents will tend to play
selfishly. The players will first have a static role that is
defined to them on a “Strategy Level”. Then on an “Individual
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
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.
A. Passing
The agents will tend to choose the agent who is least likely to
be intercepted while deciding who to pass the ball to. To
estimate this, the agents will use the view that is free and the
distance of the other agent from them.
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
B. Gap creation
The supporting players will tend to move so as to increase
the interception angle to make it easier for the player with the
ball to pass.
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
C. Dribbling
Dribbling consists of kicking the ball forward with a small
force and then following the ball. The force of the kick will be
inversely proportional to the distance of the closest opposing
player near the player that is dribbling and in the direction of
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. 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.
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, [email protected],
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
35
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