RoboPET Team Description Paper

RoboPET Team Description Paper
Cristiano M. Dalbem, Eduardo M. Leonardi, Dennis G. Balreira, Suya P. Castilhos, Mauro J. Moreira,
Dante A. C. Barone
{cmdalbem, dgbalreira, emleonardi, spcastilhos, barone}@inf.ufrgs.br
Abstract— This paper presents an overview of the RoboPET
2011 project, a Robocup Small Size League team of Brazilian
undergraduate students of Computer Science, Computer Engineering, Mechanical Engineering and Electrical Engineering.
This paper will outline the most important details of both the
robot hardware and the software architecture.
I. I NTRODUCTION
RoboPET is a robot soccer team, under the Small Size
F180 category, developed at the Federal University of Rio
Grande do Sul. The team has participated in Robocup
2009 and has, despite some problems, obtained some good
results. In the second semester of 2009 the team has gone
through a major refactoring, from the decision system to the
mechanical structure of the robot. By the time of the writing
of this paper the new physical robots aren’t ready, but the
project described here is the architecture we’ve designed and
in which we are working on now.
A. Vision
The SSL Vision. When we are in a real game (as opposed
to a simulated game), it receives the images from the field
and sends the data (positions and IDs of the robots and the
ball) to the Tracker.
Fig. 1.
RoboPET’s Software Architecture
II. S OFTWARE
We’ve developed a modular architecture (Fig. 1), in which
each module is a separate executable file. The communication is done through UDP sockets, and the serialization/deserialization uses Google Protocol Buffers [1] for uncoupled information exchanging and easy module swapping.
This even makes it possible to run the system in a distributed
manner if by any means necessary.
A. Vision
Gets debugging information about the internal state of AI,
it’s actions. Futurely will send settings to AI (e.g. manually
setting a machine state, manual control of a robot, etc.).
Due to changes in the rules for the category this year, all
teams must use SSL Vision [2]. We are adapting ourselves
to it and we intend to soon start to contribute with its code.
In addition to the Vision system, we use a Tracker module
which filters the information given by the first. It’s packets
usually give separated information of the two cameras, each
on a socket message, and the task of our filtering is to
aggregate it’s parts and pass a consistent version to AI.
There’s also a basic handling of multiple balls, that decides
which is the most probable of being the real ball. In the
future, it will also take in account information sent by the
Radio, e.g. battery charge and speed of the robot measured
by the encoders.
E. Radio
B. Artificial Intelligence
When we are in a real game, receives the actions of AI
and sends them to the robots, sending feedback from the
robots (speed and battery charging) to the Tracker.
The decision making has been split in two different steps.
The first one is the reasoning based in the information
queried from our world model and the second is the path calculation to determine an optimized path without collisions.
1) Decision System: Our decision system tries to abstract
the many nested condition tests that are inherent to decision
making by utilizing state machines. Each state represents an
action to be taken and each transition can lead to another
state or to a new machine. Thus the decisions are made
by “navigating“ through state machines in an hierarchical
B. Tracker
The task is find out the real position of the players and
the ball, given it’s approximated information by Vision.
C. Simulator
Receives the actions of the AI, simulating the results and
sending them to the Tracker.
D. GUI
The tests with real robots are done whenever needed, with
a constantly mounted field of 1/3 from the dimensions a real
RoboCUP field.
This work was supported by CNPq and SETEC/MEC
All the authors are within Federal University of Rio Grande do Sul. Av
Paula Gama, 110, Porto Alegre/RS
manner, where the current state of the first machine leads
to the second, the second leads to a third, and so on until
reaching the lowest level, which determine the action of each
robot.
The team is priorizing an approach that separates the decisions in two levels: the upper one being purely declarative
and consisting of state machine specification, and the lower
one being the actual code that implements the actions and
transitions. The state machines are specified in the HiSMaS
language [11], a language developed by the group which
draws inspiration from XABSL [12] and is highly focused
in being simple and letting the complicated code be done
efficiently in the host language. This approach turned out to
be very advantageous because it allows high reuse of code
and a greater clarity.
The Lua programming language [3] is used for the specification of agents. The languange, being of interpreted type,
allows us to change these specifications without having to
recompile or restart the program. Another advantage is that
the code is less bureaucratic, which facilitates maintenance
and early contributions by new members of the group.
2) Pathplanning: We implemented the A* [5] and Rapidly
Exploring Random Trees (RRT) path-planning algorithms
[4], which are already consolidated in the literature. Our
current working version of RRT is based on grids, but we
are developing a continuous version of it, which we believe
will be faster and more accurate.
We are also developing a new algorithm, the G* (provisory
name), based on bounding geometries (i.e. a bounding box of
arbitrary forms) around obstacles. The idea is to navigate on
the vertices of these geometries, which is a very easy way of
avoiding collisions. We believe it will be the faster solution
of our arsenal, with yet a solution close to the optimal.
Our future plans are to implement optimized versions of
those canonical algorithms. Such versions include the D*
[6] and the ERRT (Extended RRT) [7], both which take
in account the environmental dynamism of a robots soccer
game.
C. Simulation
Our intent with the Simulation Module is to test a handful
of components of our architecture with a agile framework, in
comparison to testing with real robots. It’s modus operandi
is to receive from the Radio the motor forces that would
be sent to real robots, together with kicking and dribling
variables. The software will the then use the information to
simulate the interaction of the physical bodies, passing the
final positions of the players and the ball to the Tracker,
emulating the existence a Vision Module.
The software was developed with a simulation library
called Box2D [10]. This simple physics library is designed
for game development and it allows us to easily simulate
colliding bodies, acceleration, inertia, friction and angular
forces. With some basic programming we have been able to
simulate kicking and dribbling of the robots.
Fig. 2. GUI Screenshot, showing a simulation of the RRT algorithm on a
hypothetic game state.
D. Graphical User Interface
The GUI (Graphical User Interface) (Fig. 2) allows us to
visualize the current state of AI in the game, embodying it’s
view of the game (is the AI viewing the world correctly?)
and the decisions taken, thus facilitating testing and error
detection. Futurely the GUI will generate a log file of
the game (real or simulated), which can then be replayed,
enabling the improvement of the team and the identification
of mistakes made and passed unnoticed. Furthermore, it
allows you to modify the behavior of the team, for example
by setting a fixed state, to facilitate testing of new or recently
modified parts.
This module has been iteratively developed in the past 2
years, from it’s first core system to additional features being
added. The programming language used is C++, together
with GTK [8] - a GUI library - and Cairo [9], a 2D drawing
library.
III. H ARDWARE
A. Eletronics
With the desire of having a fast and efficient hardware
able to control the robot and provide a feedback, we’ve
developed a modular eletronics divided in four parts: KickerBoard, DribblerBoard, DriverBoard and MotherBoard. This
approach also facilitate possible repairs, in case of a hardware
failure.
1) Driverboard: The Driverboard is responsible for controling the DC Brushless motor spin. The four DriverBoards
- one for each wheel’s motor - are connected to the Motherboard and they receive the speed each motor must develop.
In addition to control the brushless motors and generate
the PWM signals to it, we use a dsPIC30F2010 PIC witch
receives the rotor’s position via hall sensors, also used to
provide a feedback of the velocity developed, and a driver
system composed by 3 half h-bridges, in order to induce
voltages in the motor’s coils. In this board there is also a
current peak detector circuit - using the Allegro ACS712 IC
- that limits the motor current up to 1,5A.
2) KickerBoard: The KickerBoard is responsible for the
robot kick, i.e., it parallelly communicates with the MotherBoard, receiving which kick to trigger(chip or normal)
and its power, thereby, activating the solenoids correctly.
To activate the solenoids it’s necessary to elevate the 18,5V
tension provided by the battery to 250V - using, for this,
two capacitors of 2700uF in parallel and a DC-DC converter
(Boost).
3) DribblerBoard: Similar to the DriverBoard, the DribblerBoard controls the robot’s dribbling system. The infrared
sensors - placed in the robot chassis to identify the ball’s
presence in front of the mechanical dribbling system - are
connected to this board. When the ball is just in front of
the robot, the board activates the dribbler motor. No encoder
system was coupled in this board, because it’s thought that
there is no need of that much precision for the dribbling
system.
4) MotherBoard: The MotherBoard is responsible for the
communication (through radio) of the robots with the main
server. The used radio is the transceiver TRW-24G of 2.4GHz
of frequency, that communicates with a 24FIJ64GB106 PIC
which receives the speed of the motors and the kick data
and returns the real speed, the ball’s presence in front of the
robot and the charge level of the batteries.
It’s through this board that all the commitments of the
robot are organized. It has an interface that allows the
adjustment and the visualization of the robot status and it’s
also able to turn on, to turn off and to restart the system.
The communication with the other boards is done both by
parallel and serial communication, depending on the quantity
of information to be transmitted.
Fig. 3.
Isometric view of the chassis.
IV. M ECHANICAL D ESIGN
The Mechanical Design covers the physical and structural
aspects of the robot. Such aspects are: the chassis, the wheels,
the motors and the dribbling and kicking mechanisms.
Previously, we could not use all of the features we designed, due to manufacture and delivery issues, and because
of this we had to assembly the robot with old and obsolete
components. Fortunately, now the physical components are
available and the robot can be assembled as we designed it.
The mechanical systems and their respective considerations are as follows:
ball in the front of the robot, respecting the limits of cover
stated by the rules. The kicking system, in its turn, consists
of a solenoid and a simple mechanism, capable of throwing
the ball horizontally as well as a parabolic trajectory.
A. Structure and wheels
C. Motors
The chassis was designed with optimization of the weight
and size, respecting the limitations stated by the rules of the
competition and with a 4-wheeled model in mind. The basic
physical structure of the robot is as shown in Figure 3.
Responsible for the locomotion of the robot, the 4 omnidirectional wheels are mounted in the chassis with an angle of
9,44 degrees, as shown in Figure 4. This angle was chosen
for both stability and friction optimization.
The motors, which, by the time of the writing of this paper
have not been delivered yet, are brushless ones, capable of
a high performance with low friction losses.
B. Dribbling and kicking
The dribbling system, coupled with the kicking system,
consists of a spongy cylinder, capable of rotating, to hold the
Fig. 4.
Angle of inclination of the wheels.
V. C ONCLUSION
This paper gave an overview of RoboPET 2011 Team,
which is not yet finished, but is under heavy development.
The new physical robots as described here shall be complete
by September 2011. Since our main problems on last years
Robocup were our robot motors and radio, we hope well
have a better performance on the next national and international competitions once the new robots are done.
R EFERENCES
[1] Google Protocol Buffers, http://code.google.com/apis/
protocolbuffers/
[2] Zickler, S., Laue, T., Birbach, O., Wongphati, M., Veloso, M.: SSLVision: The Shared Vision System for the RoboCup Small Size League.
In: Proceedings of the RoboCup Symposium 2009 (2009)
[3] Ierusalimschy, R., de Figueiredo, L. H., Celes, W.: Lua - an extensible
extension language. Software: Practice & Experience 26 #6 (1996)
635652.
[4] Bruce, J.R.: Real-Time Motion Planning and Safe Navigation in Dynamic Multi-Robot Environments. PhD thesis, Carnegie Mellon University (Dec 2006)
[5] Hart, P. E., Nilsson, N. J., Raphael B.: A formal basis for the heuristics
determination of minimum cost paths. In: IEEE Transactions on Systems
Science and Cybernetics, SSC-4, pg. 100-107. (1998)
[6] Anthony, S.: Optimal and Efficient Path Planning for Partially-Known
Environments. In: Proceedings of the International Conference
on Robotics and Automation (1994)
[7] Lavalle, S. M.: Rapidly-Exploring Random Trees: A New Tool for Path
Planning (1998)
[8] The GTK+ Project, http://www.gtk.org/
[9] cairographics.org, http://www.cairographics.org/
[10] Box2D Physics Engine, http://www.box2d.org/
[11] Silveira, K. S.: Hierarchical State Machine Specification (2010),
http://hismas.googlecode.com
[12] Lotzsch, M., Risler M., Jungel M.: XABSL - A Pragmatic Approach
to Behavior Engineering. In: Proceedings of IEEE/RSJ International
Conference of Intelligent Robots and Systems (IROS) (2006)