background image

CMDragons 2009 Extended Team Description

Stefan Zickler, James Bruce, Joydeep Biswas,

Michael Licitra, and Manuela Veloso

Carnegie Mellon University

{

szickler,jbruce,veloso

}

@cs.cmu.edu

{

joydeep,mlicitra

}

@andrew.cmu.edu

Abstract.

In this paper we present an overview of CMDragons 2009,

Carnegie Mellon’s entry for the RoboCup Small Size League. Our team
builds upon the research and success of RoboCup entries in previous
years. Our team’s success can be contributed to a well-balanced combi-
nation of sophisticated robot hardware and a layered, intelligent software
architecture consisting of computer vision, multi-robot play selection, as
well as single robot tactics and navigation.

1

Introduction

Our RoboCup Small Size League entry, CMDragons 2009, builds upon the on-
going research used to create the previous CMDragons teams (1997-2003,2006-
2008) and CMRoboDragons joint team (2004, 2005). Our team entry consists of
five omni-directional robots controlled by an offboard computer. Sensing is pro-
vided by two overhead mounted cameras linked to the offboard computer. The
software then sends driving commands to the individual robots. This first half
of this paper describes the robot and vision hardware of the system. The second
half of this paper describes the overall architecture and individual components
of the offboard control software required to implement a robot soccer team.

2

Hardware

The modern Small Size League has brought along many challenging demands
on hardware. To perform well as a team, robots need to be reliable, fast, and
accurate in their actuations. Similarly, global vision sensing needs to not only
be low-latency, but also needs to have sufficient resolution to accurately localize
the robots and the ball on the relatively large field. This Section describes these
hardware components of our system.

2.1

Vision

In previous years, the CMDragons team has relied heavily on traditional off-the-
shelf camcorders in conjunction with low-cost capture cards as its vision system.
Our previous hardware delivered a 640

×

240 pixel video stream at 60Hz. The

pdftohtml_folder/2009_ETDP_CMDragons-html.html
background image

2

continued increases in field size however, have led this system to reach its limits
in terms of resolution. Another limitation of this traditional vision hardware is
the inability to modify video settings without physically interacting with the
camera which is mounted above the playing field. To overcome these issues,
CMDragons 2009 features two new IEEE 1394B (Firewire 800) cameras (AVT
Stingray F-46C) which provide a 780

×

580 YUV422 progressive video stream

at 60Hz, thus delivering roughly three times as much data throughput as our
previous system. Each camera is connected to the central computer via two
dedicated PCI-Express IEEE 1394B cards. The images delivered by the cameras
are then processed by the vision software which is described in detail in Section
3.1.

2.2

Robots

Fig. 1.

A CMDragons robot shown with and without protective cover.

Our team consists of seven homogeneous robot agents, with five being used

in a game at any point in time. In Figure 1, an example robot is shown with and
without a protective plastic cover. The hardware is the same as used in RoboCup
2006-2008. We believe that our hardware is still highly competitive and allows
our team to perform close to optimal within the tolerances of the rules. Thus,
we are not likely to introduce any major changes to the robotic hardware for
2009. Instead, we focus our efforts on improving the software to fully utilize the
robots’ capabilities instead.

The robot drive system and kicker are shown in Figure 2. Each robot is omni-

directional, with four custom-built wheels driven by 30 watt brushless motors.

pdftohtml_folder/2009_ETDP_CMDragons-html.html
background image

3

Each motor has a reflective quadrature encoder for accurate wheel travel and
speed estimation. The kicker is a large diameter custom wound solenoid attached
directly to a kicking plate, which offers improved durability compared to designs
using a standard D-frame solenoid. The kicker is capable of propelling the ball
at speeds up to 15

m/s

, and is fully variable so that controlled passes can also be

carried out. The CMDragons robot also has a chip-kicking device in the style of
FU-Fighter’s 2005 robot design. It is a custom-made flat solenoid located under
the main kicker, which strikes an angled wedge visible at the front bottom of
the robot. The wedge is hinged and travels a short distance at a 45% angle from
the ground plane, driving the ball at a similar angle. It is capable of propelling
the ball up to 4

.

5

m

before it hits the ground. Both kickers are driven by a bank

of three capacitors charged to 200

V

. The capacitors are located directly above

the kicker and below the electronics, leading to our unusual mechanical design
which lacks a single connected “midplate”. By using a slightly thicker baseplate,
and several partial midplates with multiple standoffs for support, we were still
able to design a highly robust robot.

Ball catching and handling is performed by a motorized rubber-coated drib-

bling bar which is mounted on an hinged damper for improved pass reception.
The dribbling bar is driven by a brushless motor so that it can achieve a high
speed without sacrificing torque. The hinged damper can also be retracted us-
ing a small servo. This is used during certain kicking maneuvers, so that the
dribbling bar does not interfere with speed or accuracy.

Fig. 2.

Top view of the robot drive system, kicker, and dribbler.

pdftohtml_folder/2009_ETDP_CMDragons-html.html
background image

4

Our robot is designed for full rules compliance at all times. The robot fits

within the maximum dimensions specified in the official rules, with a maximum
diameter of 178mm and a height of 143mm. The dribbler holds up to 19% of the
ball when receiving a pass, and somewhat less when the ball is at rest or during
normal dribbling. The chip kicking device has a very short travel distance, and at
no point in its travel can it overlap more than 20% of the ball due to the location
of the dribbling bar. While technically able to perform kicks of up to 15

m/s

, the

main kicker has been hard-coded to never exceed kick-speeds of 10

m/s

for full

rule compliance.

The robot electronics consists of an ARM7 core running at 58MHz linked

to a Xilinx Spartan2 FPGA. The ARM7 core handles communication, runs the
PD drive control calculations, and monitors onboard systems. The FPGA im-
plements the quadrature decoders, PWM generation, serial communication with
other onboard devices, and operates a beeper for audible debugging output.
Figure 3 shows the main electronics board which integrates all electronic com-
ponents except for a separate kicker board and IR ball sensors. This high level
of integration helps to keep the electronics compact and robust, and helps to
maintain a low center of gravity compared to multi-board designs. Despite the
limited area, a reasonable amount of onboard computation is possible. Specifi-
cally, by offloading the many resource intensive operations onto the FPGA, the
ARM CPU is freed to perform relatively complex calculations.

Fig. 3.

The main robot electronics board for CMDragons 2006.

pdftohtml_folder/2009_ETDP_CMDragons-html.html
background image

5

Fig. 4.

The general architecture of the CMDragons offboard control software.

3

Software

The software architecture for our offboard control system is shown in Figure 4.
Our entire software architecture has been written in C++ and currently runs
under Linux. It follows the same overall structure as has been used in the previous
year, outlined in [1, 2]. The major organizational components of the system are
a server program which performs vision and manages communication with the
robots, and two client programs which connect to the server via UDP sockets.
The first client is a soccer program, which implements the soccer playing strategy
and robot navigation and control, and the second client is a graphical interface
program for monitoring and controlling the system. The details of the soccer
program are described in the following Sections.

The server program consists of vision, tracker, radio, and a multi-client server.

In past years, the vision system used CMVision2 for low-level image segmenta-
tion and connected region analysis [3, 4] with an efficient and accurate algorithm
for pattern detection described in [5]. This year, however, we are intending to
transition to the new, and still experimental, SSL shared vision system. Some
of the integration details are described in Section 3.1 of this paper. Tracking is
achieved using a probabilistic method based on Extended Kalman-Bucy filters
to obtain filtered estimates of ball and robot positions. Additionally, the filters
provide velocity estimates for all tracked objects. Further details on tracking are
provided in [6]. Final commands are communicated by the server program using
a radio link as described in Section 3.2. Alternatively to running the server which
observes and interfaces with the actual robots, it is also possible to employ the
simulator which appears semantically identical to the server, but uses an inter-
nal, physics-based world model. The details of this simulator are described in
Section 3.3.

pdftohtml_folder/2009_ETDP_CMDragons-html.html
background image

6

3.1

Vision

Coincidental with the improvement of vision hardware, CMDragons 2009 has
also switched its image processing software to the new Small Size League Shared
Vision System,

SSL-Vision

. This vision system is currently under heavy devel-

opment by volunteers from several teams, including CMDragons. SSL-Vision is
released as open source and is therefore available to all teams. In order to use
SSL-Vision, the “Vision” component in Figure 4 is effectively being replaced
with a network client that receives packets from the SSL-Vision system. These
packets will contain the locations and orientations of all the robots, as well as
the location of the ball. However, data fusion of the two cameras and motion
tracking will continue to be performed within our system, as SSL-Vision does
not currently support such functionality.

For competing in RoboCup 2009, SSL-Vision should provide several advan-

tages compared to CMDragons past year’s system. One major improvement is
the geometry calibration of the cameras. Our previous system required the use of
paper calibration patterns to be carefully placed on the field for calibration pur-
poses. SSL-Vision does not require any such calibration patterns and can be fully
calibrated through its user interface. Another improvement is that SSL-Vision
provides direct access to all DCAM parameters of our Firewire cameras, thus
allowing configuration of settings such as exposure, white balance, or shutter
speed, during runtime. Finally, SSL-Vision contains a very open and extendible
architecture, allowing the interchangeability of different image processing “plug-
ins”. This will allow teams to develop their own improvements and extensions to
the system, such as faster image processing algorithms or improved calibration
routines. It furthermore allows quick switching and performance comparisons
between such plugins.

Even though these improvements sound very promising, there is a poten-

tial risk of transitioning to SSL-Vision: the system is still very new, its source
base is still under heavy development, and has had little real-world testing. We
feel however, that the benefits of SSL-Vision greatly outweigh its risks, and we
furthermore hope that our early adoption of the system will provide a positive
example and impact on the Small Size League, leading to a quick maturation of
the system.

3.2

Wireless Communication

Wireless communication with the robots is performed in the 902-927 MHz fre-
quency range through the Linx HP3 module connected via a standard serial port.
The CMDragons robots are fully equipped with both receivers and transmitters
which provides them with bi-directional communication abilities, thus not only
allowing the central software to control the robots, but also allowing the con-
trol software to receive IR sensor feedback and battery status from the robots.
However, due to the added latency of these robot observations, the system relies
mostly on one-way communication for control only. Sensor observations however,
are used if vision data becomes unavailable (e.g. in case of occlusion).

pdftohtml_folder/2009_ETDP_CMDragons-html.html
background image

7

3.3

Simulator

Being able to accurately simulate robot behaviors is an integral part of our
team’s development cycle. Simulation allows rapid testing of new code without
the need to impose drain on our robotic hardware. Additionally, it allows us to
simulate scenarios which we are unable to recreate by our limited number of
physical robots, such as full five-on-five RoboCup games. In recent years, our
ball-manipulation capabilities and behaviors have become very sophisticated.
Our strategies often rely on complex dynamics interactions such as deflecting a
ball off from opponents. The introduction of chip-kicks has added the additional
requirement of three-dimensional simulation. Finally, many of our most recent
behaviors rely heavily on our robots’ ball-dribbling capabilities, and thus should
also be accommodated in a simulated model.