Bemb e l b o t s F r a n k f u r tRoboCup SPL Team at Goethe University FrankfurtTeam Description for RoboCup 2013Dipl.-Inf. Markus Meissner1, Dr. Holger Friedrich2, Dipl.-Inf. Andreas Fürtig1,Dipl.-Inf. Tobias Weis2, Jens-Michael Siegl1, Christian Becker1, VincentMichalski1, Gerhard Ruscher1, B.Sc. Andreas Kehlenbach1, Dipl.-Math. AnnaReckers1, Konrad Zacharias1, Eric Hanssen1, and Alexander Heun1

1Goethe University, Frankfurt, Germany2Frankfurt Institute for Advanced Studies, Frankfurt, Germany

teamleader@bembelbots.de

1 Team Bembelbots

The Joint Robotics Lab (JRL) is a joint project ofthree working groups of the Institut of ComputerScience at Goethe University Frankfurt with thecommon goal to strengthen project oriented learn-ing.Early 2009 the JRL offered a working group, calledRoboCup-AG. Within this group up to ten studentsstarted developing a robot behaviour using the sim-ulator Webots1. Still in the same year this ini-tial team founded the RoboCup team BembelbotsFrankfurt. The whole team was very motivated al-ready from the beginning, met several times a weekand everybody spent a lot of free time to performstrongly. This was necessary as right from the start,we decided to build our own framework from scratchinstead of using already existent frameworks.Due to fast satisfying results we participated in theRoboCup German Open, already in 2010. Sincethat time, we took part every year, gaining a lotof experience. We also obtained new practicaland theoretical knowledge through visiting openRoboCup workshops in Berlin, through playingfriendly matches and exchanging knowledge withother teams. Thereby we made continuous progressimproving our framework. We implemented a ro-bust vision, a satisfying self localisation, a dynamicbehaviour, an own walk and much more. As a re-sult of our efforts we got the chance to participate inthe RoboCup World-Championship in 2012 and en-joyed the experience of our first international com-petition very much.

During the years the team members changed butoverall it grows continuously.

Figure 1: Team Bembelbots at the RoboCup GermanOpen2013

Team Structure: Team leader of Bembelbots isMarkus Meissner, a PhD student at the ElectronicDesign Methodology group at the Institute of Com-puter Science at the Goethe University Frankfurt.He has a good overview of the team members’ activ-ities and is very avid, especially in the developmentof behaviour and motion. Dr. Holger Friedrich, for-mer head of the team, has left Goethe University,but still spends a lot of his free time for the team, es-pecially in the areas vision, framework and softwaredevelopment methodology. Andreas Fürtig just fin-ished his studies and wrote his diploma thesis oncolour classification [2]. He is now a dedicated PhDstudent at the Joint-Robotics-Lab, dealing with or-ganisational issues and coordinates the work withthe new students and research projects..We have several senior students with strong contri-butions to the RoboCup. Tobias Weis has finishedhis diploma thesis on self localisation [3] and is stillworking continuously on improving the localisation,

1http://www.cyberbotics.com

1

Christian Becker also finished the work on his thesison advanced line detection and scan-matching algo-rithms [4]. Jens Siegl contributes technical knowl-edge and maintains the robots since the beginningof the project. Andreas Kehlenbach provided theinfrastructure for XABSL and works on enhancingthe walk-engine. Christian Becker and AlexanderHeun develop behaviours and Gerhard Ruscher con-centrates on motions. Anna Reckers is the contactfor mathematical problems. In addition we haveseveral students who joined the RoboCup team inthe last years. Konrad Zacharias, Eric Hanssen andfour additional students recently joined the teamand are still searching for their field of interest.

2 Research Interests and PlannedActivities

Focusing on computer vision development in thepast years, the team Bembelbots made fast progresstowards a reliable image based self localisation andtherefore was also able to enhance the robots be-haviour concerning game strategies.In the last years the their selves from this frame-work: faster walks and an overall improved agilityare promising enhancements that legitimate the de-velopment of a self-made motion engine. Hencewe started to disengage from the NaoQi and de-veloped our own walk and are taking further stepsto develop a completely self-contained motion en-gine. Gerhard Ruscher is currently working on acomplete new motion engine interacting with theDCM directly in his diploma thesis.

3 Summary of Past Relevant Work

3.1 Software Framework

We developed our own software framework fromscratch. It is written in C++ and consists of sev-eral modules. We compile against the NaoQi mid-dleware, but have minimized the dependencies andwrapped library dependent calls. In addition toNaoQi we use external libraries OpenCV, libbzip,Boost, and the XABSL engine. For the future weare planning to amplify the split-off of the NaoQifrom our framework. The following paragraphs givean overview of the key aspects we focused on duringthe last three years.

3.1.1 Development Methodology

We have a strong focus on automated testing. Ourbase software framework is compiled and tested ev-ery time new code is checked into our source codemanagement system. The unit test framework weuse is googletest2, and we check the coverage of ourtests with a profiling tool gcov from the GNU Com-piler Collection suite. Continious Integration withJenkins builds the whole framework on different sys-tems everytime the code is changed and ensures astable framework at any given time.

3.1.2 Locomotion

Walking Engine: Our first implementation for anown walk was based on [7]. As the paper proposed,we implemented a closed-loop walk.However the stability of that walk was too bad forreal walking. Our robots were able to dribble, butnot to walk. Further tests and literature researchguided us to an open-loop walk engine.According to that and with the helpful assistanceof Team Nao-HTWK of Leipzig we successfully de-veloped a full parametrizable walk implementationduring the last year. A joypad control has beendeveloped to comfortably set the parameters.

Kick: We implemented three kinds of kicks: front,back and side kick. The Nao chooses the type ofkick due to the implemented behaviour. In addi-tion, each kick is parametrizable, where the robothimself computes the right parameter dependant onthe ball position.

3.1.3 Cognition

Camera Like most teams, for a long time we usedonly one camera. Regarding the increasing fieldsizein 2013, it became more necessary to have a far-reaching view. Seeing the goal at the end of thefield is as important as seeing the ball directly infront of the robots’ feet. That is the reason whywe decided to use both cameras and adapted theexisting algorithms to use this new potential.

Classification The cognition process is mainlysplit into two parts. In a first step, colour classifica-tion is applied to the high resolution image. Clas-sification is based on a Gaussian model describingthe statistics of the colour values. A fast implemen-tation using Lookup Tables guarantees a process-ing rate in real time [1]. After this step, the envi-ronment is separated into 6 different colour classes,

2http://code.google.com/p/googletest/

2

which can easily be processed in order to find impor-tant elements on the field. The classification step isvery robust to changes in illumination, which typ-ically appear in competitions or show events, andthus there is no need to calibrate the Lookup Tableby hand before each game.To deal with the new field dimensions, we decidedto use both cameras of the Nao. Both images arenot processed in parallel, instead we toggle the cam-eras in each step to save computational power. Dueto a high framerate of nearly 30 processed imagesper second, this means we classify 15 images of eachcamera per second.To minimize cache-misses, which lead to a slowerprocessing rate, the whole Lookup Table was alsocompressed [2]. A result image of the classificationstep can be seen in Fig. 2.

Detecting Objects Based on the fact that thecolour-classification provides very good results, thesubsequent object recognition modules work on bi-nary images of each colour class of interest. Mainlyhistograms on this binary images are used to findobjects of interest, like goals and balls. This methodcomes with the benefit of being very robust on asmall number of misclassified pixel values.Besides simple geometry checks on the shape of theobjects to be recognized, a feedback loop has beenimplemented relating the distance of an object toits dimension. After calibration of the robots, weachieved good results for distance measurementsbased on triangulation.

Figure 2: Result of the Dual Vision Module. Left column:Original Image (converted to RGB), right column: Classifi-cation of the input image with found vision results: A ball,yellow goalpoles and several corners, which then are processedby the localisation module.

Detecting Lines, Corners, and the Centre CircleThe colour classified images are scanned with hor-izontal and vertical scanlines to find green-white-green transitions. Currently we are developing amethod, that not only takes colour into account

but also makes use of flanks in the illuminationchannel of the YUV -image. The scanline distanceis adjusted based on the distance of image pointsprojected onto the ground-plane, such that the dis-tance between scanned points on the ground isalways less than 5cm.Detected line points will be connected to lines,and in a second step lines that match in spaceand orientation will be joined. These lines arethen projected onto the ground-plane of the robot-coordinate-system. In this space, known geometri-cal relations between field lines are applied, easingthe detection of the centre circle and the corners.

3.1.4 Localisation

During the past year our main focus of attentionwas the improvement of our localisation methods.The detection of lines, corners, the centre circle andpoles (as explained above) are used for computingall likely positions of the robot in the world.The more features detected in one picture or themore expressive the detected features are, the lesspositions are likely (a detected goal equals two likelypositions on the field, where a single L-Corner yieldseight possible positions). Every possible positioncalculated like this is a measurement for the Kalmanfilter. However, the benefit of different colouredgoals is no longer existent and the feasibility of fol-lowing more than just one track is a crucial con-straint.The additional symmetries introduced by two goalsof the same colour implicate an increasing variety ofrobot positions for a single measurement. The in-creasing number of field players further decreasesthe possibility of detecting strong landmarks, soVincent Michalski and Tobias Weis implementeda Multi Hypothesis Kalman Filter and introducedtwo new measurements for breaking the symmetry.The use of infrared emission by the goalkeeper aidsthe localisation of field players by providing a stronghint about their orientation and about their fieldhalf (IR range is approx. 3m). Fused ball positions(especially with the goalkeeper) also provide usefulinformation about the field half, and, in the caseof a successfully fused team-ball, about their posi-tions.For cases where little information is available forlocalisation (e.g. only one line), we are developinga Scan-Matching approach based on [10] to providesome kind of local position estimation.The detected field lines and other features will bematched to the known environment, given the po-sition estimate. To minimize the lookup of whichdetected feature should be matched to which of the

3

world we use a similar approach like [11]. This willallow position correction even with very little infor-mation. Fig. 3 shows an example.

Figure 3: Top: The soccerfield underlayed with a voronoimap. Each colour corresponds to a fieldline. This map isused for lookup. White the detected fieldlines, projected tothe ground at the believed robot position (green).Bottom: Magnified view after the Scan-Matching process.The grey dots represent the former detected lines. It is easyto see that the overlay is much better. Red is the correctedposition on the field.

Figure 4: Live visualisation of the hypotheses of the kalmanfilter with according covariances. The direct result of thecurrent measuremnt (goal) is shown in pink, the most likelyhypothesis in red.

3.1.5 Behaviour

We integrated the XABSL engine into our frame-work and implemented a wrapper class, to parse ar-guments from the framework to the behaviour andvice versa.

3.1.6 Scaleable field size

Based on the announcement to enlarge the field in2013 we will no longer be able to construct a fullsized field in one of the institutes rooms. Thereforewe restructured all modules and external tools toutilize a centralized variable field definition. Thisalso allowed the construction of a smaller, perma-nent field in one of our lab rooms.

3.1.7 Isolation of our software from NaoQi

Until this year we built a big library including oursoftware and related NaoQi functionality. At themoment we are pushing the separation of our soft-ware and the communication with NaoQi. There-fore our software will run separatly and will com-municate with NaoQi via several shared memories.A lot of code can be reused from the old frame-work, but a lot of testing will still be necessary.Because of that, we hope to get this running untilthe RoboCup in Eindhoven, including a completenew debug framework and tools.

3.2 ToolsSeveral tools have been developed in the last years,allowing us to debug and analyse the behaviourof our Naos. Those tools are written in Python,mainly for portability purposes. They work eitherwith Linux, Windows and partly also on mobilephones (Android). NaoDebug is the main applica-tion to debug the robot, for example change cameraparameters or receive live images. The current stateof the XABSL FSM can be displayed graphically, aswell as the current state of the world model of therobots and their estimated positions in the world.This speeds up the whole development process, aserrors are detected very early and easily.Our old remote tool to control the robot for demon-stration purposes was merged with NaoDebug. Anold version of the remote (NaoRemote) is still avail-able on the team home page [8].

References1. Fürtig, Andreas; Friedrich, Holger; Mester, Rudolf

(2010): Robust Pixel Classification for RoboCup,Farbworkshop Ilmenau

2. Fürtig, Andreas (2011): Farbklassifizierung für hu-manoide Roboter im RoboCup Umfeld, Diplomathesis at Goethe-University, Frankfurt

3. Weis, Tobias (2011): Selbstlokalisierung für hu-manoide Roboter im RoboCup Umfeld, Diplomathesis at Goethe-University, Frankfurt

4. Becker, Christian (2013): Linienbasierte Feature-detektion und Positionstracking durch Voronoi-

4

Diagramme in einer symmetrischen Umgebung ,Diploma thesis at Goethe-University, Frankfurt

5. Rohnfeld, Erik (2010): Reinforcement Learning zumLernen eines Schusses auf dem Nao-Roboter, Bach-elor thesis at Goethe-University, Frankfurt

6. Jäger, Moritz (2010): Entwicklung eines automa-tisierten Verfahrens zur Optimierung der Laufbewe-gung des Nao Roboters, Bachelor thesis at Goethe-University, Frankfurt

7. Behnke, Sven (2006): Online Trajectory GenerationFor Omnidirectional Biped Walking

8. NaoRemote for Nao Robot (2012):www.bembelbots.de/web/robocup/downloads/

9. Quinlan et al.:The 2005 NUbots team report. Tech-nical Report, The University of Newcastle, 2006.

10. Cox, Ingemar J. (1991): Blanche - An Experiment inGuidance and Navigation of an Autonomous RobotVehicle

11. Whelan, T. et al (2012): Line point registration: Atechnique for enhancing robot localization in a soc-cer environment

5