ICARUSControl Systems for Search and Rescue Robots

Christopher Armbrust1, Geert De Cubber2, and Karsten Berns1

1 Robotics Research Lab, Department of Computer Science, University of Kaiserslautern,P.O. Box 3049, 67653 Kaiserslautern, Germany, {armbrust,berns}@cs.uni-kl.de

2 Unmanned Vehicle Centre, Department of Mechanics, Royal Military Academy,Av. De La Renaissance 30, B1000 Brussels, Belgium, geert.de.cubber@rma.ac.be

Abstract. This paper describes results of the European project ICARUS in thefield of search and rescue robotics. It presents the software architectures of twounmanned ground vehicles (a small and a large one) developed in the context ofthe project. The architectures of the two vehicles share many similarities. This al-lows for component reuse and thus reduces the overall development effort. Hence,the main contribution of this paper are design concepts that can serve as a basisfor the development of different robot control systems.

1 Introduction

The research described in the paper at hand is part of the vast field of search and rescue(SAR), which consists of many sub-fields that target at various situations and differingcircumstances. The ICARUS1 project, however, focuses on two of these areas: urbansearch and rescue (USAR) and maritime search and rescue.

USAR deals with a variety of hazards, including earthquakes, tornadoes, technolog-ical accidents, and even terrorist attacks. All of these hazards represent high dangers tofirst responders. Hence, the use of robots that can assist first responders and thus reducetheir risk is desirable. While there is a lot of literature describing fundamental researchin this field, there are comparably few publications about practical progress towardstools that end users can buy and deploy during their mission. Exceptions are publica-tions from a number of projects funded by the European Commission in the context ofthe Seventh Framework Programme for Research (FP7): DARIUS (see [1]), NIFTi (see[2] and [3]), and SHERPA (see [4]). ICARUS is also an FP7 project, equipped with a bud-get of around 17.5 MC. Its aim is to develop tools that can be used by crisis managersdirectly after they have reached the site of an incident. These tools can be unmannedsea, air, or ground vehicles (see [5] and [6]) that are equipped with sensors for detectinghumans, but also devices that can be used to establish communication links betweenfirst responders (see [7]). Figure 1 illustrates some scenarios that ICARUS targets at.

There are various crisis scenarios in which unmanned ground vehicles (UGVs) canbe used. Each of the scenarios makes a number of requirements on the UGV that shall beused in that specific scenario (see Sec. 2.1). Therefore, the intended use of a vehicle hasa major influence on its design. It is not possible to incorporate the requirements for all

1 ICARUS: Integrated Components for Assisted Rescue and Unmanned Search Operations

Fig. 1. An illustration of the two main scenarios (earthquake, naval accident) thatICARUS targets at.

scenarios into the design of one single UGV. Hence, different types of UGVs are neededfor different scenarios. In order to reduce the development effort, it is highly reasonableto design them in a way that architectural concepts or single components can be usedon different vehicles. The paper at hand presents the control architecture and the designconcepts proposed by the ICARUS project.

The remainder of this paper is structured as follows: Section 2 presents requirementsfor UGVs that have been identified in the ICARUS project and introduces the hardwareplatforms used for the ICARUS UGVs. It is then explained in Sec. 3 how the controlsystems of the two different ICARUS UGVs have been designed in a way that manycomponents can be used on both vehicles. Finally, Sec. 4 summarises the main contri-butions of this paper and provides an outlook on the next steps in the ICARUS projectwith respect to UGVs.

2 ICARUS UGV Platforms

This section describes the requirements that have been taken into account during thedesign of the UGVs of the ICARUS project. It also describes the hardware platforms forthe vehicles.

2.1 Requirements

An important aspect of ICARUS is the constant involvement of end user feedback.Hence, members of the Belgian First Aid and Support Team (B-FAST) were asked inwhich way UGVs could help them during their SAR operations. Their answers resultedin the identification of the following two types of robotic platforms:

1. A large UGV (LUGV) could serve as mobile base. Equipped with several sensorsfor environment perception, it could help in collecting information about dangerousplaces and store it or directly send it to the end users. The LUGV should also featurea large robotic arm along with several tools (e.g. a gripper for removing debris).

2. A small UGV (SUGV) could serve as robotic vanguard that enters narrow dangerousplaces like collapsed buildings and provides a first assessment of the situation tothe crisis personnel. The vehicle could be used to search for trapped victims with aspecial human detection device. Some of the SUGV’s sensors could be attached toa small arm so that looking into small, confined places would be possible.

The descriptions of the two UGVs show that the applications of (and thus require-ments on) robotic ground platforms in SAR scenarios can be hard or impossible to unitein one single type of vehicle. For example, a platform that shall carry a robotic armthat is powerful enough to be used for removing debris needs a certain size and anappropriate on-board energy source. However, such a platform will be far too large tomanoeuvre in narrow places like a collapsed building. On the other hand, a platformthat is small and lightweight enough to be used in damaged structures will certainly notbe able to carry numerous complex sensor systems let alone a powerful manipulator.

For this reason, the ICARUS members decided to develop two vehicles with theabove-mentioned basic characteristics. The strength of having two different UGVs isthat they are most effective when acting within one SAR team, but that they can also beused independently of each other. An example scenario for the combined use of the twovehicles is a site that was hit by an earthquake. Controlled by a remote operator, theLUGV can drive along damaged buildings and provide data with which emergency per-sonnel can make a first estimate of the situation. In case the road is blocked by smallerdebris, the operator can use the vehicle’s arm to remove the blockade. During these op-erations, the vehicle assists the remote personnel with its autonomous capabilities, e.g.collision avoidance. Furthermore, the LUGV is able to carry the SUGV to a damagedbuilding that shall be further investigated. In this case, the SUGV is regarded as a toolcarried by the LUGV. The SUGV can be unloaded at the building and be driven into itso that the remote operator can get an impression of the interior. That way, the LUGV’sability to cover large distances and clear the road of smaller obstacles is combined withthe SUGV’s ability to investigate difficult to access areas. But even if the LUGV is notavailable (e.g. because it could not be transported to the emergency site in time), theSUGV alone can assist crisis managers during an operation.

The advantage of using UGVs in SAR scenarios is that first responders can assessthe site of an incident without risking their lives. With the use of two UGVs of differenttypes, different scenarios can be addressed. Due to the availability of a powerful arm,the crisis managers not only have remote sensors at their command, but also a device tomanipulate the environment. To reduce the overhead of developing two vehicles instead

of only one, the control systems of the vehicles are developed in a way that manycomponents can be used on both vehicles (see Sec. 3).

2.2 Platforms

In the following, the two hardware platforms are described in detail.

2.2.1 Large Unmanned Ground Vehicle Figure 2 depicts a CAD model of the baseplatform for the LUGV provided by ICARUS consortium member Metalliance2. It isa chain-driven vehicle that measures approx. 3 m by 2 m by 1.8 m (length by widthby height) and has a weight of around 2,300 kg. Its tracks lend the LUGV a plannedheight-crossing ability of 30 cm and a gap-crossing ability of even 60 cm. Hence, it iswell-suited for harsh terrain as can be expected at an emergency site. A combustionengine powers the hydraulic systems of the chain drive and the arm. It is also connectedto a current generator that supplies the on-board electronic systems. With a payloadcapacity of 300 kg, it can easily carry tools for the arm or the SUGV. The vehicle’s armhas 5 DOF and can lift objects of up to 250 kg. It will be possible to control the armfrom a remote location using an exoskeleton.

For localisation purposes, the LUGV will be equipped with a sophisticated GPSreceiver (Trimble BX982) and an inertial measurement unit with integrated magneticcompass (MicroStrain 3DM-GX1).

Fig. 2. A CAD drawing of the LUGV.

A number of external sensor will be available to provide information about theLUGV’s environment. Two laser ranger finders (SICK LMS511) will be mounted on thevehicle—one at its front and the other at its back. A Velodyne HDL-32E will yield3D information about the world around the LUGV, while a custom-built stereo vision

2 http://www.metalliance-tsi.com/

system as well as a commercial stereo camera with an integrated terrain traversabilityanalysis and obstacle detection system (see [8] and [9]) will provide 3D informationabout the area in front of the robot. The external sensors will provide the data for theLUGV’s collision avoidance system and will be used by rescue teams to remotely controlthe vehicle. Especially the cameras will be helpful in this regard. Industrial computersfrom DSM Computer will run the control system.

2.2.2 Small Unmanned Ground Vehicle The SUGV (see Fig. 3) is based on a DigitalVanguard formerly produced by ICARUS consortium member Allen-Vanguard3. It is asmall tracked platform that measures approx. 104 cm by 45 cm by 56 cm (length bywidth by height) and weighs around 60 kg. It features a ground clearance of around6 cm and can climb slopes of up to 45°. The platform provides a small arm that is,just like the tracks, powered by electric motors. Due to limitations in size and weight,it is impossible to equip the vehicle with large, sophisticated sensor systems like theSICK LMS511. Instead, it will be equipped with a rotating SICK TiM551 and a pan-tilt-zoom camera—allowing an operator to remotely control it—as well as a structured lightsensor (ASUS Xtion PRO LIVE) and a stereo camera system based on two BFLY-PGE-13S2M-CS from Point Grey Research, Inc. These sensors shall be used for collisionavoidance. As on the LUGV, an industrial computer from DSM Computer will run thecontrol system.

Fig. 3. The SUGV on rough terrain. The blue box is the control computer. On the baseof the arm, the two cameras constituting the stereo system are mounted. In front of thebase, the structured light sensor can be seen. The pan-tilt-zoom camera and the laserrange finder have not yet been mounted.

3 http://www.allenvanguard.com/

3 Control System Architecture

In this section, the planned architectures of the systems controlling the two ICARUSUGVs is described. All components of the control systems as well as the simulation envi-ronment have been or will be implemented using the software framework FINROC (see[10], [11], and http://www.finroc.org/), which is developed at the Robotics Re-search Lab of the University of Kaiserslautern, Germany. Section 3.1 gives an overviewof the control systems, while Sec. 3.2 focuses on the components for sensor processingand navigation.

3.1 UGV Control Systems - Overview

Figure 4 depicts a high-level overview of the components building the UGVs’ controlsystems. It shows that they are built up in a highly layered fashion. Distributing a con-trol system’s functionality over different components organised in layers is a commonapproach. The authors of [12], for example, follow this approach in the context of theDARPA’s LAGR project.

Figure 4 also shows that the two control systems have similar structures at this level.The only difference is that the control system of the LUGV might provide a componentfor mission planning. Having similar structures (or even the same structure) for bothcontrol systems yields advantages when designing and implementing them as well asduring their validation or the addition of new components.

In the following, the components of the UGV control systems shall be describedbriefly. For early testing and safe evaluation of the developed concepts, a sophisticatedsimulation environment is used that reflects the essential aspects of the real system.However, due to the complex nature of the vehicles, their application environment, andthe planned scenarios, some aspects cannot be covered by the simulation tool.

At the lowest level of each control system, the hardware abstraction layer (HAL)builds an interface to either the simulated or the real UGV. The HAL is used by all othercomponents of the control system for accessing the vehicle’s sensors and actuators. Anadvantage of this approach is that the various parts of the control system can controla real or a simulated platform without the need for adaption, i.e. at the levels abovethe HAL, there should ideally be no difference whether a simulated or a real vehicle isrun. As a result, the overhead for switching between the two is reduced to a minimum.Furthermore, the software development could start long before the UGV platforms wereavailable without the need to invest significant work into switching to the real platformsonce they were available.

As the HAL is strongly hardware-dependent, it is specific to the electronic systemsavailable on a platform. The low-level electronics for controlling the tracks of the SUGVwas developed by Robot Makers GmbH4. Space is limited on the SUGV. Therefore, thecompact CUBE System was chosen. The Robot Makers GmbH provides a C++ driverlibrary and bindings for FINROC. Thus, connecting the electronics to the control systemis straightforward. In a similar way, the electronics for controlling the SUGV arm willbe connected to the control system.

4 http://robotmakers.de/en/

The PLC5 installed by Metalliance on the LUGV platform for controlling its trackshas a CAN bus interface. Hence, the HAL provides a FINROC driver for the device. TheLUGV arm is also controlled with electronic components developed by Robot MakersGmbH. These communicate with FINROC like the hardware mentioned before. As theparts are mounted on the arm, the waterproof variant of the CUBE System was deployed.In this case, a task of the HAL is to calculate coordinate transformations needed forinterfacing between the high-level arm control and the low-level electronics controllingthe hydraulics. For example, the inverse kinematics problem has to be solved to convertTCP6 coordinates into joint angles.

LUGV Control System SUGV Control System

Real LUGVSimulated LUGV Real SUGVSimulated SUGV

Human OperatorsTelemetry

Commands

Telemetry

Commands

Communication Layer

SensorProcessing

Navigation

Hardware Abstraction Layer

Communication Layer

SensorProcessing

Navigation

Hardware Abstraction Layer

Mission Planning

Commands /Telemetry

Commands /Telemetry

Commands /Telemetry

Commands /Telemetry

Fig. 4. A high-level overview of the control systems of the LUGV and the SUGV. Thecommunication between the rescue teams and the vehicles is also depicted. Each controlsystem can be used to either control a simulated or a real vehicle. Both systems sharea similar structure. As the SUGV is more limited in terms of its computational power,it does not provide high-level mission planning. The box for the mission planning istransparent, indicating that the control system might not contain this component. Thereason for this is that such high-level autonomy is usually rejected by the end users.

5 PLC: programmable logic controller6 TCP: tool centre point

The sensor processing component is responsible for controlling the sensors, gath-ering their data, and processing it in a way that it can be used by other components ofthe control system, e.g. the navigation system. It comprises building different types ofmaps that represent different aspects of a vehicle’s environment and are tailored to thespecific needs of the components using them. For example, a path planning algorithmon a high level may be interested in the topology of the environment, while the collisionavoidance, operating at a lower level, requires precise information about hazards in thevicinity of the robot. Section 3.2.2 provides more information about this.

The navigation component realises localisation, obstacle avoidance, and path plan-ning. It is the responsibility of the navigation system to determine the UGV’s currentpose and to move it safely in various environments to its target locations. The lattercan be provided by an operator or—if present—the mission planning component (seebelow).

The communication layer provides the operators with easy access to the platforms,e.g. by providing sensor data or interfaces that allow for controlling the vehicle. Asthe future operators of the UGVs will be SAR teams (i.e. people typically not fromrobotics), it is necessary that the communication component provides every interfacethat is needed in order to control the vehicles with input devices that are well-suited forbeing used by rescue personnel during SAR operations. One of these devices will be anexoskeleton provided by ICARUS partner Space Applications Services7, which shall beused to control the powerful manipulator on the LUGV (see Fig. 5 and [13]).

At the moment, no direct communication between the LUGV and the SUGV is fore-seen. Instead, all of the communication is transferred via the ICARUS communicationinfrastructure. However, as the SUGV may not have a good network connection withina building, there are plans to use the UGV as relay for the communication of the SUGVwith the remainder of the ICARUS network.

Fig. 5. The exoskeleton provided by ICARUS partner Space Applications Services. Itshall be used to control the manipulator on the LUGV (source: [7]).

7 http://www.spaceapplications.com/

The mission planning component will understand commands like “Drive to the near-est victim!” and will be able to preprocess them for the navigation system. For the men-tioned command, this would require asking the sensor processing (or an external datasource via the communication layer) for information about victims and then calculatingthe position of the nearest one. However, surveys have shown that such a high degreeof autonomy is usually rejected by the end users, so it is possible that this componentwill not be realised. In this case, the end users will have to provide more information tothe robot, e.g. the position of the nearest victim.

As described, the high-level structure of the control systems is highly modular. Eachof the components itself is also built up in a highly modular way. Therefore, the systemsare easy to extend and it is possible to reuse some of their components on other plat-forms or use components originally developed for other robots in the control systemsof the ICARUS UGVs.

3.2 UGV Control Systems - Sensor Processing and Navigation

Figure 6 gives an overview of the components for sensor processing and navigation aswell as their interaction. The focus is on the steps for processing data of the externalsensors (e.g. laser range finders) and how the results are used to calculate actuator com-mands. The figure also depicts how a user can send inputs to the navigation system.However, several aspects of the navigation system (like the localisation components)are left out for reasons of clarity. Components that process sensor data (e.g. for mapbuilding) and data structures (like maps) are coloured in blue, while components cal-culating targets or actuator commands are coloured in orange. Two green rectanglessymbolise the communication and the hardware abstraction layers.

The structure of this part of the UGVs’ control systems closely resembles the cor-responding parts of the control system of the autonomous off-road vehicle RAVON (see[14]) as it is described in [15]. RAVON is used in the ICARUS project as test platform forearly evaluation of concepts and algorithms. The reason that the control systems of theICARUS UGVs are built up in a similar way is that the separation of the complete systeminto components in the depicted way has proven to have several advantages:

1. The clear separation of the processing of sensor data from the calculation of controlvalues facilitates using the same navigation components on vehicles with differenttypes of sensor systems.

2. The sub-division of the sensor processing into single elements that mainly dealwith one sensor each facilitates the reuse of sensor processing algorithms acrossdifferent platforms with different sensor facilities.

3. The combination of different navigation approaches increases the flexibility of thesystem with respect to changing environments and varied user requirements.

A big difference between the ICARUS UGV control systems and RAVON’s controlsystem is that at the moment, only a local path planner is foreseen on the level of themid-range navigation. In contrast to the possible application scenario of RAVON, thescenarios of the ICARUS UGVs are limited to disaster scenarios—which is still quitea wide spectrum. Therefore, navigation approaches like the detection of passages as

Short-Term

Memories

Short-Term

Memories

Short-Term

Memo-ries

FusionGrid Map

Abstract Views

(Virtual Sensors)

Abstract Views

(Virtual Sensors)

Abstract Views

(Virtual Sensors)

TargetApproach

CollisionAvoidance

Local PathPlanning

Hardware Abstraction Layer

Global Path Planning

Communication Layer

PreprocessedSensorData

RawSensor

Data

ActuatorCommands

User Commands

DistantTarget

Topo-logical

Map

DistantTarget

Inter-mediate

Target

CloseTarget

Inter-mediate Target

NextTarget

Velocity and

Heading

Filtered Velocity

and Heading

PreprocessedSensorData

Calculation of Topology

Grid Map Creation

Data Abstraction

Fusion

Target Selection

Data ProcessingComponent

Data Flow

Control Flow

ControlComponent

Data Structure

ExternalComponent

Velocityand

Heading

Velocity and Heading Selection

Velocity and Heading

Long-RangeNavigation

Mid-RangeNavigation

Short-RangeNavigation

Velocity and Heading Selection

Velocity and

Heading

Velocityand

Heading

Fig. 6. An overview of the sensor processing and navigation components of the UGVcontrol systems. The blue components are related to sensor data and sensor data pro-cessing, while the orange components deal with calculating commands that are ulti-mately sent to the vehicle’s actuators. The green rectangles indicate other layers of thecontrol systems.

described in [16] or the detection of trails are not included in the navigation systems ofthe ICARUS UGVs.

In the following, the components responsible for sensor processing and navigationshall be described briefly.

3.2.1 Components for Sensor Processing The grid map creation gets as input pre-processed data from the external sensors and from this data creates grid maps that areused as short-term memories. All grid maps are centred at the robot and move with it,but are fixed in their orientation. As a result, a grid map covers an area around the robotand contains information about this area. Thanks to the usage of short-term memories,the vehicle’s navigation system can react to obstacles in the environment that are cur-rently not in the scope of the vehicle’s sensors. For each sensor and each type of dataanalysis algorithm, a grid map is created that only contains information about the en-vironment retrieved from this specific sensor using this specific algorithm. The reasonfor this separation is that on this level, no fusion of sensor data shall be performed sothat bottlenecks are avoided and the processed data can be stored into the grid maps at ahigh rate. In Fig. 7, the test platform RAVON is shown in an outdoor environment (7a). Acorresponding grid map created from the data of a 3D laser range finder mounted on thefront of the robot is depicted next to it (7b). Sector maps (see below) are superimposedonto the grid map.

(a) Photo depicting RAVON in an outdoorenvironment; its front is pointing to theright (source: [15]).

(b) A grid map of the robot’s environ-ment created from data of a 3D laserrange finder with superimposed sec-tor maps (source: [15]).

Fig. 7. The test platform RAVON in an outdoor environment (a) and a correspondinggrid map with superimposed sector maps (b).

The environment information stored in a grid map is typically quite complex asthere are many classes of obstacles (e.g. positive obstacles, negative obstacles, or over-hanging obstacles). Positive obstacles start at the ground and have an upward extent likerocks or walls, while negative obstacles are cavities in the ground like holes or abysses.Overhanging obstacles, finally, have a larger extent at the top than at the bottom like a

tree with large branches. The high information density of grid maps makes them diffi-cult to process. In case the collision avoidance system would directly operate on thesedata structures, the respective algorithms would get unnecessarily complicated. Further-more, they would have to be adapted each time a grid map with new types of obstacleswould be added. Therefore, the data is further abstracted into virtual sensors. Each ofthese is represented by a sector map that is fixed with respect to the robot. There are twotypes of sector maps: polar and Cartesian ones. Polar sector maps divide the area theycover into a number of equal segments of a circle, while Cartesian sector maps divide itinto equal rectangles. Figure 8 depicts polar (8a) and Cartesian (8b) sector maps of thetest platform RAVON. Each sector of a sector map contains the distance to the closestobstacle in the area it covers. This abstract information is completely sufficient for col-lision avoidance and much easier to retrieve from sector maps than directly from gridmaps. Hence, by encapsulating the abstraction into a dedicated component, the colli-sion avoidance system can be designed in a more generic and straightforward way (seeSec. 3.2.2).

(a) A polar sector mapcovering an area in frontof the test platformRAVON (source: [17],adapted).

(b) Two Cartesian sector maps covering two areasin front of the test platform RAVON (source: [17],adapted).

Fig. 8. Polar (a) and Cartesian (b) sector maps covering areas around the test platformRAVON.

As will be described below (see also Sec. 3.2.2), the local path planning compo-nent requires a view on the environment that is combined by the processed data of allexternal sensors. Hence, a sophisticated fusion component combines all grid maps intoone, which then serves as basis for the local path planner. Details about the fusion tech-nique (and also about the data abstraction) can be found in [17], where it is describedextensively.

Grid maps are not well-suited for representing large environments. They typicallyrequire large amounts of memory and do not provide information about the topologyof places. Hence, a topological map is created from preprocessed sensor data. Its only

purpose is to serve as database for the global path planning. Each node of the map corre-sponds to a place relevant to the navigation of the robot. Each edge between two nodesprovides information about whether the robot can get from the place corresponding tothe first node to the place corresponding to the second node and further information likethe costs for getting from one node to the other.

3.2.2 Components for Navigation At the highest layer, the user will be able to inputcommands. These are typically a desired velocity and heading or the coordinates of thenext target to which the UGV shall navigate.

Target coordinates will be used as input for the global path planning, which willoperate on the above-mentioned topological map of the environment. The A* algorithmwill be used to calculate paths from a starting point to a destination within the topolog-ical map. This is necessary as usually, a vehicle cannot drive directly to its next goal ina complex environment. The result of the path planning will be a list of intermediatetargets leading to the final target.

The intermediate targets generated by the global path planning will normally besent one by one to the local path planner, which will calculate the shortest path basedon a grid map. This grid map is the result of fusing all grid maps into one as describedin Sec. 3.2.1. Like the global path planner, the local path planner will employ the A*algorithm. As the scope of the fusion grid map is smaller and its information densityis higher than that of the topological map, it is possible to plan a precise path aroundobstacles in a reasonable time. Such a path will consist of a number of path points thatthe UGV shall follow to its final target.

In many cases, the target points calculated by the local path planner will be sentfurther down the hierarchy of control components. In some cases, however, the operatormight decide that the next point the UGV shall approach shall be taken directly fromthe global path planning or he might even set the immediate target by himself. Hence,a selection of the next direct (immediate) target will be performed and the resultingcoordinates will be sent to the component realising the target approach. The latter willcalculate the desired velocity and heading of the UGV for approaching the immediatetarget based on the target’s coordinates and the vehicle’s pose. In case the operatordecides to directly steer the UGV, he can send a desired velocity and heading to thecontrol system and override the target approach. This is realised by another selectioncomponent.

Before the desired velocity and heading can be forwarded to the HAL, where theywill be used to generate actuator commands, the vehicle’s collision avoidance systemwill filter or overwrite them with values that guarantee a safe motion in case this isnecessary. The anti-collision component will be realised as behaviour-based system.In contrast to monolithic architectures, behaviour-based systems are composed of a(possibly large) number of single components, the behaviours. Each of them realisesa certain aspect of the robot’s overall functionality and tries to influence the robot in acertain way. The overall behaviour of the robot is then the result of the interaction of thebehaviours constituting its control system. Advantages of such systems are their easyextensibility and their support for distributed development and testing. There is a lot ofliterature about behaviour-based systems. The author of [18] describes several aspects

and in the Springer Handbook of Robotics (see [19]), a whole chapter is dedicated tothem (see [20]). The behaviour architecture used in the control systems of the ICARUSUGVs will be the iB2C8 (see [21]). Each behaviour dealing with collision avoidancewill monitor the contents of a sector map and get active depending on the distance tothe obstacles listed in that map. If the robot can continue on its path without getting tooclose to an obstacle, the behaviours of the safety system will let the commands from thehigher layers pass down to the HAL. In case the commands lead to a dangerous situation,the behaviours will overwrite them with other values and in this way guarantee that thevehicle does not hit an obstacle.

The operator shall always have full control over the vehicle. Hence, he will be ableto bypass the anti-collision system and directly send his velocity and heading commandsto the HAL. In this mode, however, the vehicle will be completely under his control andthus will not be able to provide any support regarding collision avoidance measures.

4 Conclusion and Future Work

This paper presented concepts for structuring the control systems of UGVs in a waythat components can be used on different platforms with different sensor systems. Itdescribed how the concepts, which originally have been developed for the off-road plat-form RAVON, will be applied to a small and a large UGV in the context of a Europeanproject in the area of search and rescue robotics.

Ongoing and future work deal with implementing these concepts during the reali-sation of the control systems of the two UGVs. Thereby, software components that arealready used on RAVON will be reused, reducing the implementation time and improv-ing the software quality.

Acknowledgement

Parts of the research leading to these results has received funding from the EuropeanUnion Seventh Framework Programme (FP7/2007-2013) under grant agreement num-ber 285417.

References

1. P. Chrobocinski, N. Zotos, E. Makri, C. Stergiopoulos, and G. Bogdos. DARIUS project:Deployable SAR integrated chain with unmanned systems. In Proceedings of the 2012 In-ternational Conference on Telecommunications and Multimedia (TEMU), pages 220–226,Heraklion, Crete, Greece, July 30 - August 1 2012. E-ISBN: 978-1-4673-2779-4; PrintISBN: 978-1-4673-2780-0.

2. Geert-Jan M. Kruijff, Viatcheslav Tretyakov, Thorsten Linder, Fiora Pirri, Mario Gianni,Panagiotis Papadakis, Matia Pizzoli, Arnab Sinha, Emanuele Pianese, Salvatore Corrao, Fab-rizio Priori, Sergio Febrini, and Sandro Angeletti. Rescue robots at earthquake-hit Mirandola,Italy: A field report. In Proceedings of the 2012 IEEE International Symposium on Safety,Security, and Rescue Robotics (SSRR), pages 1–8, College Station, Texas, USA, November5-8 2012. Print ISBN: 978-1-4799-0164-7.

8 iB2C: integrated Behaviour-Based Control

3. G.J.M. Kruijff, M. Janıcek, S. Keshavdas, B. Larochelle, H. Zender, N.J.J.M. Smets,T. Mioch, M.A. Neerincx, J.V. Diggelen, F. Colas, M. Liu, F. Pomerleau, R. Siegwart,V. Hlavac, T. Svoboda, T. Petrıcek, M. Reinstein, K. Zimmermann, F. Pirri, M. Gianni, P. Pa-padakis, A. Sinha, P. Balmer, N. Tomatis, R. Worst, T. Linder, H. Surmann, V. Tretyakov,S. Corrao, S. Pratzler-Wanczura, and M. Sulk. Experience in system design for human-robotteaming in urban search and rescue. In Kazuya Yoshida and Satoshi Tadokoro, editors, Fieldand Service Robotics, volume 92 of Springer Tracts in Advanced Robotics, pages 111–125.Springer Berlin Heidelberg, 2014. ISBN-13: 978-3-642-40685-0.

4. L. Marconi, C. Melchiorri, M. Beetz, D. Pangercic, R. Siegwart, S. Leutenegger, R. Carloni,S. Stramigioli, H. Bruyninckx, P. Doherty, A. Kleiner, V. Lippiello, A. Finzi, B. Siciliano,A. Sala, and N. Tomatis. The SHERPA project: Smart collaboration between humans andground-aerial robots for improving rescuing activities in alpine environments. In Proceed-ings of the 2012 IEEE International Symposium on Safety, Security, and Rescue Robotics(SSRR), pages 1–4, College Station, Texas, USA, November 5-8 2012.

5. Gert De Cubber, Daniela Doroftei, Yvan Baudoin, Daniel Serrano, Karsten Berns, Christo-pher Armbrust, Keshav Chintamani, Rui Sabino, Stephane Ourevitch, and TommasoFlamma. Search and rescue robots developed by the european ICARUS project. In Pro-ceedings of the IARP Seventh International Workshop on Robotics for Risky Environments- Extreme Robotics (7th IARP RISE-ER 2013), Saint Petersburg, Russia, October 1-3 2013.International Advanced Robotics Programme.

6. Thomas Pfister and Karsten Berns. Unmanned ground vehicles for urban search and res-cue in the EU-FP7 project ICARUS. In Karsten Berns, Christian Schindler, Klaus Dreßler,Barbara Jorg, Ralf Kalmar, and Gregor Zolynski, editors, Proceedings of the 3rd Commer-cial Vehicle Technology Symposium (CVT 2014), pages 13–22, University of Kaiserslautern,Kaiserslautern, Germany, March 11-13 2014. Shaker Verlag.

7. Shashank Govindaraj, Keshav Chintamani, Jeremi Gancet, Pierre Letier, Boris van Lierde,Yashodhan Nevatia, Geert De Cubber, Daniel Serrano, Miguel Esbri Palomares, JanuszBedkowski, Christopher Armbrust, Jose Sanchez, Antonio Coelho, and Iratxe Orbe. TheICARUS project - command, control and intelligence (C2I). In Proceedings of the 11th IEEEInternational Symposium on Safety, Security, and Rescue Robotics (SSRR 2013), Linkoping,Sweden, October 21-26 2013. IEEE RAS.

8. Alberto Broggi, Elena Cardarelli, Stefano Cattani, and Mario Sabbatelli. Terrain mappingfor off-road autonomous ground vehicles using rational B-spline surfaces and stereo vision.In Proceedings of the 2013 IEEE Intelligent Vehicles Symposium (IV), pages 648–653, GoldCoast, Australia, June 23-26 2013. IEEE.

9. Geert De Cubber and Daniela Doroftei. Multimodal terrain analysis for an all-terrain crisismanagement robot. In Proceedings of the IARP HUDEM 2011, Sibenik, Croatia, 2011.

10. Max Reichardt, Tobias Fohst, and Karsten Berns. On software quality-motivated designof a real-time framework for complex robot control systems. Electronic Communicationsof the EASST, Software Quality and Maintainability(60), August 2013. http://journal.ub.tu-berlin.de/eceasst/article/view/855.

11. Max Reichardt, Tobias Fohst, and Karsten Berns. Design principles in robot control frame-works. In Informatik 2013, Lecture Notes in Informatics (LNI), Koblenz, Germany, Septem-ber 16-20 2013. Springer.

12. Pierre Sermanet, Raia Hadsell, Marco Scoffier, Matt Grimes, Jan Ben, Ayse Erkan, ChrisCrudele, Urs Miller, and Yann LeCun. A multirange architecture for collision-free off-road robot navigation. Journal of Field Robotics - Special Issue on LAGR Program, PartI, 26(1):52–87, January 2009.

13. Pierre Letier, Elvina Motard, and Jean-Philippe Verschueren. EXOSTATION : Haptic ex-oskeleton based control station. In Proceedings of the 2010 IEEE International Conference

on Robotics and Automation (ICRA), pages 1840–1845, Anchorage, Alaska, USA, May 3-82010.

14. Christopher Armbrust, Tim Braun, Tobias Fohst, Martin Proetzsch, Alexander Renner,Bernd-Helge Schafer, and Karsten Berns. RAVON – the robust autonomous vehicle for off-road navigation. In Yvan Baudoin and Maki K. Habib, editors, Using robots in hazardousenvironments: Landmine detection, de-mining and other applications, chapter RAVON – TheRobust Autonomous Vehicle for Off-road Navigation. Woodhead Publishing Limited, 2010.ISBN: 1 84569 786 3; ISBN-13: 978 1 84569 786 0.

15. Bernd-Helge Schafer, Christopher Armbrust, Tobias Fohst, and Karsten Berns. The applica-tion of design schemata in off-road robotics. Intelligent Transportation Systems Magazine,IEEE, 5(1):4–27, Spring 2013.

16. Christopher Armbrust, Bernd-Helge Schafer, and Karsten Berns. Using passages to supportoff-road robot navigation. In Joaquim Filipe, Juan Andrade-Cetto, and Jean-Louis Ferrier,editors, Proceedings of the 6th International Conference on Informatics in Control, Automa-tion and Robotics (ICINCO 2009), pages 189–194, Milan, Italy, July 2-5 2009. Institute forSystems and Technologies of Information, Control and Communication (INSTICC).

17. Bernd-Helge Schafer. Control System Design Schemata and their Application in Off-roadRobotics. RRLab Dissertations. Verlag Dr. Hut, 2011. ISBN: 978-3-86853-865-6.

18. R. Arkin. Behaviour-Based Robotics. MIT Press, 1998. ISBN-10: 0-262-01165-4; ISBN-13:978-0-262-01165-5.

19. Bruno Siciliano and Oussama Khatib, editors. Springer Handbook of Robotics. SpringerBerlin Heidelberg, 2008. ISBN: 978-3-540-23957-4.

20. Maja J. Mataric and Francois Michaud. Behaviour-based systems. In Bruno Sicilianoand Oussama Khatib, editors, Springer Handbook of Robotics, chapter 38, pages 891–910.Springer Berlin Heidelberg, 2008.

21. Martin Proetzsch. Development Process for Complex Behavior-Based Robot Control Sys-tems. RRLab Dissertations. Verlag Dr. Hut, 2010. ISBN: 978-3-86853-626-3.