Fast Robot Prototyping with the CubeSystemAndreas Birk

International University Bremen, Germanya.birk@iu-bremen.de, http://robotics.iu-bremen.de/

Abstract— The CubeSystem is a collection of hardware- andsoftware-components for fast robot prototyping. The main goalof the CubeSystem project is to provide an open source collectionof generic building blocks that can be freely combined intoan application. This paper describes the first release of theCubeSystem, that evolved in more than five years of researchand development. The benefits of the CubeSystem are illustratedby several applications, ranging from educational activities toindustrial projects.

FINAL VERSION

@conference{birk_cube_icra04,AUTHOR = {Birk, Andreas},TITLE = {Fast Robot Prototyping

with the CubeSystem},BOOKTITLE = {Proceedings of the

International Conferenceon Robotics and Automation, ICRA},

PUBLISHER = {IEEE Press},YEAR = 2004}

I. INTRODUCTION

In the past, there have been several projects dealing withsoftware packages for sub-tasks in robotics like generic kine-matics [1], user interfaces for tele-operation [2], or distributedcontrol systems [3]. A more recent and more general examplein this line of research is the Open Robot Control Software(Orocos) project that includes a real-time motion kernel,CORBA-inspired communication primitives for robotics andtask execution sequencing [4], [5], [6].

All these projects are based on the assumption that a robot’shard- and software are two rather distinct parts, that can beeasily brought together by the usage of the right type ofabstractions and interfaces. This view is to quite some extentvalid when it comes to the development of application softwarefor commercial of the shelf robot hardware. But the develop-ment of a robotics application often includes the engineering ofthe hardware side as well. The CubeSystem therefore tries tooffer a component collection for fast prototyping of completerobots, i.e., the hardware and the software side.

The most basic parts of the CubeSystem are• RoboCube: a special embedded controller, or more pre-

cisely controller family, based on the MC68332 processor• CubeOS: an operating system, or more precisely an OS

family• RobLib: a library with common functions for roboticsThe general CubeOS and RobLib are collections of software

components that can be customized and combined to a par-ticular set of libraries suited for a particular application. Take

CubeOS

RobLib

application program

processor boardbus boardbase board

sensors, motors, mechanics, power

software

hardware

Fig. 1. The structure of a CubeSystem application (left), for example inform of a mobile robot for soccer playing (right).

I/O extensionExt BusmasterCPU + MEM

86mm

40mm

77mm

Fig. 2. A RoboCube processor-, bus- and I/O-board stacked together, leadingto a compact controller hardware.

for example a simple soccer robot based on the CubeSystem(figure 1). The RobLib provides for example generic functionsfor controlling a two wheeled differential drive. To controlthe two motors of the concrete robot some customizationis needed. This includes defining the mechanical parameterslike the gear-ratio, the wheel diameter and so on, as wellas the specification of the software drivers in CubeOS toservice the pulse-width-modulation of the motor drivers andthe quadrature decoding of the motor encoders.

The CubeSystem also allows quite some flexibility to adoptthe hardware side to the actual application. The RoboCube orshort Cube features some standard electronic components likethe processor-, bus-, and I/O-board that are combined with amore application specific base-board. The boards are equippedwith a special stacking connector that allows to put severalboards on top of each other. The compact form factor of theboards and the stacking leads to a cubic shape of the controller(figure 2), hence the name RoboCube. The organization of theCube architecture can be thought of in a tree-like manner. Atthe root is the minimal Cube, namely a processor-board. Itcan be expanded by a bus-board. This new branch adds newfunctionalities like, e.g., UARTs and I2C controllers that allowto expand to further branches, for example in form of certain

sensors.So, a CubeSystem application is a concrete instance of a

collection of components, for example in form of a mobilesoccer robot. As a matter of convenience, we use the termCubeSystem for both the general collection of componentsas well as for a concrete application. The same holds forRoboCube, CubeOS, and RobLib, which are used to both referto the general collection of components as well as to particularinstances for concrete applications. This difference betweenthe CubeSystem and a CubeSystem is important.

Section II presents the hardware side and section III thesoftware side. In section IV, the versality of the CubeSystem isillustrated with several of its applications. Section V concludesthe paper.

II. THE HARDWARE SIDE

A. The Processor Board

There are many possibilities for the computational hardwareof a robot, including embedded PCs like PC104 systems [7],personal digital assistances (PDA) [8], [9], dedicated robotcontrol boards like the handyboard [10], [11], or even toy-kitslike Lego Mindstorms [12] or Fischertechnik Computing [13].Unfortunately, none of these approaches provides

• an open-source• collection of components• suited for a wide variety of robotics applications.

Fig. 3. The processor board with the MC68332 CPU and the memory (left),a bus- (middle) and an I/O-board (right).

The support of almost arbitrary robotics applications inhardware is a highly ambitious goal. Especially, when consid-ering the wide range of design constraints like necessary com-putation power or available budget. The RoboCube concept isbased on a tree-like design scheme with core components atthe root that can be expanded by branches that add additionalfunctionality. Components that are up in the tree are standardcomponents, so to say off the shelf parts for any group workingwith the CubeSystem. The further down the tree, the moreadditional engineering is needed, potentially including thedesign of new electronics.

At the very root of the tree is the so-called processor-board with a Motorola MC68332, 1Mb RAM, and 1Mb Flash-EPROM. As explained in more detail later on, the main ideaof the RoboCube CPU is to provide

• sufficient computation power• for basic I/O and control• in a predictable wayIn order to be suited for different end-user applications,

RoboCube is built as an open bus system. As shown in

SPI ext

I/OBin

TP ext

Motors

UHFtrcv

IR send

IR recv

ADC/DAC

CPUROM

RAMExtensionBusmaster

I/OSubsystem

Data, Adr, /CS, /IRQ, TP, SPI, 2xI2C, 3xRS232

Fig. 4. A block diagram of the RoboCube bus architecture.

figure 4, a global bus comprises several sub-buses which aremanaged from different sources. Multiple RoboCube boardsare interconnected with two special AMP 60-pin verticalstacking connectors. This enables the user of the RoboCubeto form an application-specific stack of RoboCube boards.

The MC68332 microcontroller provides the address bus,data bus, special timing channels (TP), interrupt lines (/IRQ),several chip selects (/CS), an SPI bus and a RS232 serial bus.The optional bus-board provides two additional serial RS232buses by a DUART and two I2C buses for which a broadvariety of sensor and actuator ICs are available. Additionally,there is a 16 bit register available that serves as fast binaryoutput.

The optional I/O-board implements 16 binary IOs, 24 analoginputs and 6 analog outputs. By the help of solder jumpersthe board can be connected to each of the two I2C buses.Hence, up to two boards can work in the same system. Themain idea of the stack-on I/O-board is to provide a generic setof interfaces to sensors and motors without the need for anyhardware development. For a more customized approach, theI/O-board can be supplemented or replaced by functionalityon the baseboard.

The so-called base-boards are an optional part of aRoboCube at a level below the generic stack-on boards listedabove. There is a variety of base-board designs already avail-able within the CubeSystem. The existing range of boardscovers for example the different power requirements of motors,namely from a few Watts to some hundred Watts. As illustratedlater on in the section on applications, a CubeSystem useris likely to find a base-board that already suits his or herapplication, and if not, it is easy to modify an existing designor to even design a completely new one.

The stack-on boards are densely packed 4-layer boards withICs in packages that require automated assembly. The base-boards in contrast are 1- to 2-layer boards that can be easilyproduced and assembled with limited production capabilitiesfor example by students and even hobbyists.

APP

DUART

FBIN I2C

KERN

LED

LIST NEWLIB

RSMSPI

TPU

TTY

XDR XDRMEMXDRSTDIO

RCJRG

LIBC

QSM

SCI

Fig. 5. The component structure of CubeOS

III. THE SOFTWARE SIDE

A. The CubeOS

The RoboCube has a special operating system, the so-called CubeOS [14]. This component-based realtime operatingsystem consists of a multithreaded nanokernel with drivers forcommunication and robotic sensors and actuators. CubeOS hasfollowing features [15]:

• preemptive/cooperative multi threading• thread create/suspend/resume/sleep/kill• IPC: signals, semaphores, message queues• data primitives: e.g., lists, buffers• control primitives: e.g., reactive control, PID control• sensor/actuator abstraction• drivers for I2C and SPI busses (device primitives, non-

blocking IO)• driver for the M68332s TPU (functions, parameters,

interrupts)• layered radio communication protocol• realtime clockAs already mentioned before, there is not the CubeOS, but

a CubeOS is linked together for a specific RoboCube. Thismeans that as soon as the hardware side is settled, especially inrespect to the presence of a bus- or I/O-board and the featuresof the base-board, the corresponding modules of CubeOS needto be parametrized, compiled and linked. Once this is done,there is a fixed CubeOS for that particular hardware targetthat can be linked to all applications for that target. Thisapproach leads to a small and highly efficient OS. As anadditional consequence, advanced users have the possibilityto freely expand the CubeSystem if needed. At the same time,a wide variety of pre-designed systems is available that needno modifications on the electronics or low level OS side.

B. RobLib

The RobLib is a library of medium to high level functionsfor robotics that builds on top of CubeOS. The RobLibprovides for example PID motor controllers based on CubeOSsoftware drivers for the motor electronics. Furthermore, theRoboLib supports dead-reckoning and motion control. For thispurpose, different drives types like differential or 3-wheeled

125 Hz IRQ

emergency control

MC68332 onboard TPU

M M

Channels: A B C D E F

QDEC 1

QDEC 1

QDEC 2

QDEC 2

PWM

PWM

update positionand orientation

update motionerrors

motion control

compute target speeds

compute correction values

set newpulsewidth

read quadraturedecoders

update PIDerrors

motor control

update sensorvalues

sanitycheck

active breakingif necessary

Fig. 6. The RobLib functions for motor and motion control.

omni-directional drive are implemented. The user only needsto choose the drive type and to provide the mechanicalparameters like the gear-ratio, the wheel diameter and so on.Much like for CubeOS, the configuration and parametrizationof the generic RobLib components is done once for a specifictarget robot. Then, the according instance of the RobLib isgenerated and can be linked to applications for that robot.

C. The Development Environment

network

compile host access host

serialcom

(robot)target

Fig. 7. CubeSystem programs are developed and compiled on a compile-host, e.g., a Unix server where the proper cross-compiler and the librariesare installed. The binaries are downloaded via an access-host, typically anarbitrary PC, to the robot.

A CubeSystem like a mobile robot is a typical embeddedsystem with an according development environment. Thestructure of the development environment is shown in figure7. The CubeSystem is connected via a serial connection tothe so-called access-host. This connection can be a simpleRS-232 cable or a wireless connection via virtual cables orBluetooth. There are several options to interface a RoboCubeto the access-host, not only in terms of the underlying phys-ical medium, but also in terms of the interface port at theRoboCube. The default is a RS-232 connection via the bus-board or if no bus-board is present in the application, anaccording connection via the base-board.

The CubeSystem is programmed for efficiency reasons onlyin C. The generation of executables, i.e., compilation andlinking, is done on a so-called compile-host. In doing so,the GNU tool chain with an according cross-compiler isused. The generic CubeOS and Roblib, as well as customizedand pre-compiled instances, are also located on the compile-host. The compile-host environment can be set up on almost

arbitrary machines and operating systems as long as there isthe possibility to install the GNU tool chain.

The environments used so far include PCs with Windowsor Linux and SUN workstations with Solaris. A Windows PCis the typical low-end solution for single users working on asmall simple robotics project. In this case, the compile- andthe access-host are usually the same machine. This approach isfor example used for educational robotics where school kidsconduct simple projects on an individual basis or in smallgroups. For serious projects that involve several programmersor for the maintenance of different projects within a work-group, the compile-host should be a real server, i.e., based on aUNIX-type operating system. In this scenario, there is a singlecompile-host running in the background and several access-hosts like laptops and personal desktop computers are usedby different researchers to work on their particular projects.

D. What about Computation Power?

network

compile host access host

RoboCubecompute host

serialcom

Fig. 8. Many robotics applications require substantial processing power inaddition to basic sensor-motor control functionalities. An on-board compute-host can be used for this purpose.

An obvious objection against the CubeSystem might be itslack of computation power. The RoboCube with its MC68332micro-controller is not suited for any high-level computationlike map-building or solving complex inverse kinematics prob-lems. But it does not need to do so. As illustrated in theapplication examples below, the computation power of theRoboCube is sufficient for many tasks, e.g., for simple robotsoccer in educational activities. For any ”serious” applications,the RoboCube can be easily integrated with a so-called on-board compute-host, e.g., in form of an embedded PC (figure8). According examples are also provided in the applicationssection below.

IV. APPLICATIONS

A. Overview

The CubeSystem has been used in various robotics applica-tions, ranging from educational activities [16], [17] over basicresearch [18], [14] to industrial applications. In the followingsubsections an overview is given, which illustrates its versality.

B. Educational Robotics

The easiness of the handling of the CubeSystem is most im-pressively illustrated in its usage within the field of educationalrobotics. A set of RoboCubes consisting of the processor-boardand a simple base-board was for example used in a series of

Fig. 9. Two robots designed for a RoboCup Junior competition goingfor the ball (top). Two school kids with the German chancellor GerhardSchroder honoring their achievements with their robot-designs based on theCubeSystem.

robotics workshops with German high school students. Theseworkshops took place as part of the so-called RIDS initiative.RIDS stands for the German phrase ”Roboter In Der Schule”,which can be translated to ”using robots in school activities”.The idea of this project is to introduce school kids to roboticsand to waken a general interest in science and technology.

The main challenge for the RIDS students was to prepare forRoboCup Junior competitions. In a RoboCup Junior contest,teams with two robots play a game of soccer [19], [20].The robots have to be fully autonomous. The floor of theplaying field is covered with a grey-scale that can be usedfor coarse location of the robots. The ball emits an activeIR signal that can be sensed by relatively simple means, i.e.,suited photo-transistors. RoboCup Junior events are part of theoverall RoboCup competitions. This international aspect andthe prospect to see a vast amount of advanced robotics researchhave a high motivational value. In addition to participations inthe German Open championship, four RIDS teams made it in2001 to the RoboCup world championship in Seattle.

C. RoboCup F180 League

An other application example of the CubeSystem is theSmall Robots League of RoboCup, the worldchampionship ofrobot soccer [21], [22]. The CubeSystem has been used onrobot teams from the Vrije Universiteit Brussel (VUB) andrecently from the International University Bremen (IUB). Theteams participated in various tournaments, including RoboCupWorld Championship’98 in Paris, RoboCup World Champi-onship’99 in Stockholm, the WDR Cup’99 in Paderborn, theRoboCup European Championship 2000 in Amsterdam, theRoboCup German Open 2002, Paderborn [23], [24], [25].

filteringspatial / temporal

Prediction

of game situationspredicate filtering

Strategic Analyzer

and filteringimage processing

Visionsoftwarecommunication

RoboTerm

camera radio

display / logging of trajectories and events

robots

Visualization

(RF-comm)(PF)

(ACK)

(WS, T)

(WS, T)

(WS, PS, T)

Fig. 10. A soccer robot team for the RoboCup small size league. The robotsare relatively small, less than 15cm diameter. Nevertheless, they feature anon-board control that relies on the CubeSystem. Furthermore, various robottypes have been developed within this line of research. The heterogeneityof the robots was significantly facilitated by the component structure of theCubeSystem.

strategies

path-planning[obstacle-avoidance, short paths]

[coordination, communication]

motion-control[vectors, curves, dead-reckoning]

operating system[drivers, tasks, control-support]

motor-control[PID-speed controller]

17 - 19 Hz

17 - 68 Hz

100 Hz

100 Hz

continuous

frequency execution time

4 - 13 msec

79 msec

0.2 msec

0.1 msec

Fig. 11. The on-board control structure of the soccer robots.

Figure 10 shows some of the robots of one team. Note thatthe robots are relatively small, namely within 15cm diameter.Nevertheless, they feature an on-board, autonomous control[26]. Without the main features of the CubeSystem, namelyefficiency and reliability, it would not be possible to implementsuch a control on-board of a robot within the physical limitsof the RoboCup small size league. Furthermore, both theIUB and the VUB team investigate heterogeneous teams [27].Obviously, heterogeneity, like having dedicated robot hardwarefor defenders or forwards, is a useful feature. On the otherhand, there is the overhead to ensure proper operation overthe different platforms. In addition, the platforms do not onlyvary within a particular team to allow for heterogeneity, butalso over the years to test and incorporate new features. In thiscontext, the CubeSystem has proven its strength as componentbased system. Certain components provide for example thesame functionality for different hardware platforms. Withoutthis, portability of the high level application code would be

impossible.

D. RoboGuard, a Mobile Security Robot

Fig. 12. The inside core (top) and a schematic overview of the differentcomponents of the RoboGuard (bottom).

The so-called RoboGuard [28], [29] is a mobile securitydevice which is tightly integrated into the existing surveillanceframework developed and marketed by Quadrox, a BelgianSME. RoboGuards are semi-autonomous mobile robots pro-viding video streams via wireless Intranet-connections to ex-isting watchguard systems, supplemented by various basic andoptional behaviors. RoboGuards fill several market-niches. Es-pecially, they are a serious alternative to the standard approachof using Closed Circuit Television (CCTV) for surveillance.

E. The IUB Rescue Robots

Fig. 13. Papa goose performing in the RoboCup 2003 competition.

Fig. 14. Mother goose at the RoboCup 2003 competition in Padua, Italy.

The IUB rescue robots are mobile robots designed to assistsearch and rescue missions in urban disaster scenarios [30],[?]. The so-called papa goose is a 6-wheeled base (figure13). Mother goose is a tracked robot (figure 14). Both robotshave been developed from scratch based on CubeSystemelectronics and software components. In addition to this em-bedded hardware, both robots carry on-board PCs allowinglocal processing of the data from various sensors. Special

highlights of these autonomous functionalities are localizationand mapping in the unstructured environment of the rescuearenas.

F. A Humanoid Torso

Fig. 15. A humanoid torso with 14 DOF in its two arms.

The majority of the CubeSystem applications so far weremobile robots. But this is more due to coincidence then toany disposition in the CubeSystem itself. Figure 15 shows ahumanoid torso based on the CubeSystem. Its 14 DOF in itstwo arms are implemented via servos that are controlled withTPU-based control and motion functions from the RobLib.

V. CONCLUSION

The paper describes the CubeSystem, an open source col-lection of hardware- and software-components for fast robotprototyping. The CubeSystem consists of generic buildingblocks that can be freely combined into an application. Theversality of the CubeSystem is illustrated via a range of diverseapplications, ranging from educational activities to industrialprojects.

Further information as well as links to thesources of the CubeSystem are available viahttp://robotics.faculty.iu-bremen.de/CubeSystem

ACKNOWLEDGMENT

The development of the CubeSystem started in the AI-lab ofthe Vrije Universiteit Brussel (VUB), Belgium. It is continuedsince Winter 2001 at the International University Bremen (IUB),Germany. Many thanks for contributions to the project go toThomas Walle and Holger Kenn. Work on the CubeSystem waspartially funded by following institutions and projects: EU 4th FW,TMR-grant ”Development of a universal architecture for mobilerobots” (ERB4001GT965154); the Flemish Institution for AppliedResearch (IWT), OZM-grant ”Autonomous Systems”, phase 1 & 2(OZM-980252, OZM-000340); IWT, ”RoboGuard” with the partnersQuadrox and IMEC-VUB ETRO; VUB Research Council (OZR),”Active Vision on Mobile Platforms” (OZR461) with the partnerVUB ETRO; OZR, ”VUB RoboCup Smallsize Team”.

REFERENCES

[1] A. Ramadorai, U. Ganapathy, and F. Guida, “A generic kinematicssoftware package,” in Proceedings of the 1993 IEEE InternationalConference on Robotics and Automation. IEEE Computer Society Press,1993, pp. 3331 –3336.

[2] V. De Rossi, P. Batsomboon, S. Tosunoglu, and D. Repperger, “Inter-active modular graphical user interface development for telesensationsystems,” in The IEEE International Conference on Systems, Man, andCybernetics. IEEE Computer Society Press, 1997, pp. 1604 –1608.

[3] A. Traub and R. Schraft, “An object-oriented realtime framework fordistributed control systems,” in Proceedings of the 1999 IEEE Inter-national Conference on Robotics and Automation. IEEE ComputerSociety Press, 1999, pp. 3115 –3121.

[4] “The open robot control software, Orocos website.”[5] A. Mallet, S. Fleury, and H. Bruyninckx, “A specification of generic

robotics software components: future evolutions of genom in the oro-cos context,” in International Conference on Intelligent Robotics andSystems. IEEE, 2002.

[6] H. Bruyninckx, “Open robot control software: the orocos project,” inProceedings of the 2001 IEEE International Conference on Roboticsand Automation. IEEE Computer Society Press, 2001, pp. 2523 –2528.

[7] “The pc 104 consortium.”[8] D. H. Williams, PDA Robotics. McGrawHill, 2003.[9] K. Mukhar and D. Johnson, The Ultimate Palm Robot. McGrawHill,

2003.[10] F. Martin, The 6.270 Robot Builder’s Guide. MIT Media Laboratory,

1992.[11] ——, “Circuits to control: Learning engineering by designing lego

robots ph.d. thesis.” MIT Media Laboratory, Tech. Rep., 1994.[12] “The lego mindstorms.”[13] “The fischertechnik website.”[14] A. Birk, H. Kenn, and L. Steels, “Programming with behavior pro-

cesses,” International Journal of Robotics and Autonomous Systems,vol. 39, pp. 115–127, 2002.

[15] H. Kenn, CubeOS, The Manual. Vrije Universiteit Brussel, AI-Laboratory, 2000.

[16] M. Asada, R. D’Andrea, A. Birk, H. Kitano, and M. Veloso, “Roboticsin edutainment,” in Proceedings of the International Conference onRobotics and Automation (ICRA). IEEE Presse, 2000.

[17] A. Birk, W. Gunther, and H. Kenn, “Development of an advancedrobotics-kit for education and entertainment of non-experts,” in 1stInternational Workshop on Edutainment Robotics, 2000.

[18] A. Birk and J. Wiernik, “An n-players prisoner’s dilemma in a roboticecosystem,” International Journal of Robotics and Autonomous Systems,vol. 39, pp. 223–233, 2002.

[19] H. Lund and L. Pagliarini, “Robocup jr. with lego mindstorms,” in Pro-ceedings of the International Conference on Robotics and Automation,ICRA’2000, 2000.

[20] H. Kitano, S. Suzuki, and J. Akita, “Robocup jr.: Robocup for edutain-ment,” in Proceedings of the International Conference on Robotics andAutomation, ICRA’2000, 2000.

[21] H. Kitano, M. Asada, Y. Kuniyoshi, I. Noda, and E. Osawa, “Robocup:The robot world cup initiative,” in Proc. of The First InternationalConference on Autonomous Agents (Agents-97). The ACM Press, 1997.

[22] H. Kitano, M. Tambe, P. Stone, M. Veloso, S. Coradeschi, E. Osawa,H. Matsubara, I. Noda, and M. Asada, “The robocup synthetic agentchallenge 97,” in Proceedings of IJCAI-97, 1997.

[23] A. Birk, H. Kenn, M. Rooker, A. Akhil, B. H. Vlad, B. Nina, B.-S. Christoph, D. Vinod, E. Dumitru, H. Ioan, J. Aakash, J. Premvir,L. Benjamin, and L. Ge, “The IUB 2002 smallsize league team,” inRoboCup-02: Robot Soccer World Cup VI, ser. LNAI, G. Kaminka,P. U. Lima, and R. Rojas, Eds. Springer, 2002.

[24] A. Birk, T. Walle, T. Belpaeme, and H. Kenn, “The VUB AI-labRoboCup’99 small league team,” in Proc. of the Third RoboCup.Springer, 1999.

[25] A. Birk, T. Walle, T. Belpaeme, J. Parent, T. D. Vlaminck, and H. Kenn,“The small league RoboCup team of the VUB AI-lab,” in Proc. of TheSecond International Workshop on RoboCup. Springer, 1998.

[26] A. Birk, H. Kenn, and T. Walle, “On-board control in the RoboCupsmall robots league,” Advanced Robotics Journal, vol. 14, no. 1, pp. 27– 36, 2000.

[27] A. Birk and H. Kenn, “Heterogeneity and on-board control in the smallrobots league,” in RoboCup-99: Robot Soccer World Cup III, ser. LNAI,M. Veloso, E. Pagello, and H. Kitano, Eds. Springer, 1999, pp. 196 –209.

[28] ——, “Roboguard, a teleoperated mobile security robot,” Control Engi-neering Practice, vol. 10, no. 11, pp. 1259–1264, 2002.

[29] ——, “An industrial application of behavior-oriented robotics,” in Pro-ceedings of the International Conference on Robotics and Automation,ICRA’2001. IEEE Press, 2001.

[30] A. Birk, S. Carpin, and H. Kenn, “The IUB 2003 rescue robot team,”in RoboCup 2003: Robot Soccer World Cup VII, ser. Lecture Notes inArtificial Intelligence (LNAI), D. Polani, B. Browning, A. Bonarini, andK. Yoshida, Eds. Springer, 2004, vol. 3020.

[31] A. Birk and H. Kenn, “A control architecture for a rescue robot ensuringsafe semi-autonomous operation,” in RoboCup-02: Robot Soccer WorldCup VI, ser. LNAI, G. Kaminka, P. U. Lima, and R. Rojas, Eds.Springer, 2003, vol. 2752, pp. 254–262.