See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/4170870

Mobile robots for search and rescue

Conference Paper · July 2005

DOI: 10.1109/SSRR.2005.1501265 · Source: IEEE Xplore

CITATIONS READS

47 1,345

3 authors, including:

H. Roth Jan Chudoba

Universität Siegen Czech Technical University in Prague
220 PUBLICATIONS   1,331 CITATIONS    21 PUBLICATIONS   765 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

LearNet View project

Autonomous Robots View project

All content following this page was uploaded by H. Roth on 08 March 2017.

The user has requested enhancement of the downloaded file.

 Proceedings of the 2005 IEEE
International Workshop on Safety, Security and Rescue Robotics
Kobe, Japan, June 2005

Mobile Robots for Search and Rescue

PeLoTe Session

Niramon Ruangpayoongsak Hubert Roth Jan Chudoba

Institute of Automatic Control
Engineering
University of Siegen
Siegen, Germany
Email:niramon.r@uni-siegen.de
Applied Computer and Software
Engineering Centre (ARS)
Wuerzburg, Germany
Email: hubert.roth@uni-siegen.de
Gerstener Laboratory, Department of
Cybernetics
Czech Technical University
Prague, Czech Republic
Email:chudoba@labe.felk.cvut.cz

Abstract – Mobile robots are integrated into a search and
rescue team as tools for searching victims in dangerous areas
that is harmful for human, as to provide the perception data
for map building, and as to follow the human entity during
the mission. The teleoperated control and the autonomous
path following is implemented on the robots for the semi-
autonomous navigation in the simulated firing scenario. This
paper focuses on the robot entities in the PeLoTe project
(Building Presence through Localization for Hybrid
Telematic Teams). The architecture of the software
integration for mobile robots into the PeLoTe system and the
experimental results are presented.
Index Terms – Mobile robot, Rescue team, Teleoperated
control, Semi-autonomous navigation.
I. INTRODUCTION
In the search and rescue operation, mobile robots are
presently developed in order to assist humans in dangerous
and risky tasks during the mission. As a team, the
corporation of human and robot can be managed by a
remote coordinator, who is located in a safe remote place
outside of the disaster area. This hybrid telematic team is
presented in [1].
As a team member, the task of a mobile robot is to
explore the unknown area and the dangerous area that is
not accessible or risky for the human. By using the
appropriate perception equipment, the mobile robot can
localize itself and also senses the surrounding in the dark
area, in which the human has low visibility. Meanwhile,
the human entity equips the sensors, a data processing unit
and a small display. He can also localize himself and sense
the surrounding in the similar way as the robots.
The mobile robots have two main functions during the
mission; one is to provide the sensor data for the mapping
module and another one is to follow the human entity.
These robots are based on the same control concept using
on the architecture of the microcontroller and the PC104.
Nevertheless, the software interface protocols of these
robots are not identical. Thus, the integration methodology
of the robot software into the PeLoTe system is designed.
This paper describes the tasks, features, functionalities,
and the integration methodology of the mobile robots in
the PeLoTe project (Building Presence through
Localization for Hybrid Telematic Teams) funded by the
European Community under the IST-program: Future and
Emerging Technologies. The experiments were performed
in the firing scenario and the experimental results are also
presented.
II. MOBILE ROBOTS
The PeLoTe project targets on the concept of creating the
presence feature via remote control and navigation, as well
as knowledge sharing in combined communities of living
and nonliving entities. The foreseen applications include
next generation teleoperation and telediagnosis systems
incorporating both humans and semi-autonomous robots,
design of highly realistic man-machine interfaces,
allowing accomplished complex teleoperation tasks.
A. Robot tasks
In the present time, most of the rescue teams only require
teleoperated robots, exception are the military that claim
autonomous robots for map building or exploration of
environment. Fire fighters are in some cases cautious
about the reliability and adaptability of autonomy, for
these cases teleoperated robots are wanted. In any case, the
robots need to provide autonomous low-level actions and
emergency handling methods in order to meet the
requirement of robustness. E.g. the robot finds the way
back in case of communication interruption. These
requirements will be addressed. Desired autonomies for
robots in a farer future are:
x Provide data for map building
x Explore the environment
x Search for wounded people in wide areas
x Carry equipments
In the opinion of the fire fighters, more autonomous
robots might be used in the farer future in order to handle
tasks on their own. Typical tasks, which are desirable to be
executed autonomously are for examples, search for
wounded people in wide areas and exploration of
dangerous areas, provide the updated map according to
detected dangerous areas from gas or fire or closed path of
building from collapses, and also to carry heavy
equipments for the firemen during the rescue mission. In
addition, the robot might perform routine tasks for saving
time for human.
Telepresence techniques are thus necessary during the
mission for mobile robots in receiving sensor data, video
image and audio from the remote places. Under semi
autonomous function, a fire fighter, who performs as an
operator can command the robot to reach a position on the

0-7803-8945-X/05/$20.00 ©2005 IEEE. 212


Fig. 1. Mapping robot
preliminary map by using the path planning and the path
following control or by using the teleoperated control.
After a command is accomplished, the robots stand by and
wait for the next command, which can be either the path
control command or the teleoperated control command.
B. Robot descriptions
There exists only few expensive rescue robots in the
market and their features are not complete according to the
project requirements. Their functionalities are limited
according to the mechanical structure and the sensors on
board. Thus, the exploited mobile robots in the PeLoTe
project are built based on the existing mobile robot
technologies. As shown in Figs. 1 and 2, the Mobile
Experimental Robot for Locomotion and Intelligent
Navigation (MERLIN) is controlled by 80C167 CR 16 bit-
processor and PC104 [2]. Two motors are the servo
steering motor and dc driving motor for the robot
orientation control and the robot speed control,
respectively. The equipments on board are encoders,
ultrasonic sensors, infrared sensors, 3-axis magnetic
compass, gyroscope, laser scanner, beacon system,
bumpers, web camera, WLAN, and white LED lamps. The
mobile robots provide sensor data for the higher layer
software interface. These data are the driven distance on
the left wheel and the right wheel, the driving speed, the
angle of the robot heading, the absolute roll, pitch, yaw
rotational angles, the battery level detector and the
obstacle distance detection.
MERLIN is remotely controlled via the programmed
client and server using java software based on TCP/IP
communication. The wireless LAN is used for wireless
data communication between user GUI and the robot. The
control commands and telemetry data from sensors are
transmitted between the client and server continuously.
In semi-autonomous teleoperated control, the user
commands the robot by using a joystick or arrow cursors
as to steer the front wheels and to propel the rear wheels.
213
Fig. 2. Human following robot
Furthermore, the user can also command by specifying
line paths or arc paths. This is called the autonomous path
following control. In this mode, the robot automatically
controls its movement along the received path and stops at
the destination using self localization. These semi-
autonomous features are integrated into the PeLoTe
system and are explained in the next section.
III. SOFTWARE INTEGRATION
The overall software architecture of PeLoTe system is
described in [1]. The detail of the robot software
integration is described in this section. From the developed
GUI and hardware interface of the robot as explained in
the previous section, an interface layer is required to
mount two or more robots into the same data and
command protocols. From different protocols into one
common protocol that is recognizable for all robots, the
Robot Entity Control Module (RECoM) is defined,
designed, and developed using java RMI for the server
communication. The RECoM is a control system
consisting of several modules. The data flow among these
modules is shown in Fig. 3.
A. Server interface module
It is necessary to keep the communication connection
during the mission. However, in some blind area, where
the WLAN signal is weak or hidden by walls, the
communication could be lost. Thus, the server interface
module responsible for establishing connection to the
PeLoTe server and provides communication with server to
other modules. In case of lost of connection, the server
interface module informs all modules and tries to re-
establish the connection.
B. Decision module
The interpretation of the path data from path planner and
notification of robot events are the functions of the
decision module. This module mainly downloads and
processes the global plan from the server that is generated
by central planning module. The global plans are then sent
to the planning module. Special procedure is needed for
the plan points marked as inspection points, where robot
stops and explores its visible vicinity. When an inspection
 SERVER INTERFACE
local localization module processes sensor data used for
the position estimation and sends the estimated position to
plan from map the server. One the other hand, the localization module
progress transfer to
server reporting also handles the corrections of robot position from the
server
operator or from the CoLo.
DECISION MAPPING
MODULE F. Direct movement control module
position In some cases, the operator may need to control the robot
global plan local position update
map correction manually using joystick or arrow cursors; the direct
PLANNING LOCALIZATION movement control module. The symbol 'direct TO conn.'
means direct teleoperator connection that is the direct
direct
trajectory messages for connection of sending and receiving the joystick control
TO.
DIRECT
teleoperator command over socket communication between GUI and
conn.
MOVEMENT DIAGNOSTICS the direct movement control module and the command is
CONTROL futher sent to the hardware abstraction layer.
G. Diagnostics module
obstacle BUMPER
MOVEMENT warning As its name, the module informs server and operators
CONTROL about robot status, e.g. battery level, and important sensor
movement sensor data data e.g. temperature, detected gas. These data are shown
commands on PeLoTe GUI as symbolic color tabs or numerical data
HARDWARE ABSTRACTION LAYER depended on the type of sensor data so that they are easily
and quickly recognizable by the operator.
Fig. 3. RECoM data flow
H. Movement control

point is reached, a message is sent to the server for
progress reporting. This is necessary for the global path
planning module on the server to know what places were
already visited, in case of the need for replanning. Another
function of the decision module is to report operators via
server of messages about unexpected events and
notifications about performed goals e.g. explored areas,
found victims, finished plan.
C. Mapping module
To support the map updating based on entities perception,
the mapping module builds map from the data obtained
from obstacle detection sensors and these maps are
transferred to the server where global map is built. The
map is then used by server for efficient replanning in case
of unexpected situation like blocked corridor. In such a
situation, the updated map is very efficient for helping the
fire fighter, who cannot find the way out from the sudden
death end caused by the destruction of walls or parts of the
building. The local map is further sent to the planning
module.
D. Planning module
The planning module takes the plan from the decision
module and the mapping module, generates the local plans
based on the obstacle detection, and sends these planned
trajectories to the movement control.
E. Localization module
In the PeLoTe system, the global and local localization
modules are integrated. The global localization module is
called the Cooperative Localization (CoLo). The CoLo
provides the correction of localization for all entities. The
CoLo process is not focused in this paper. On RECoM, the
Here, the trajectory plan from the planning module is
translated into robot movement commands and sent to the
robot via the hardware abstraction layer.
I. Bumper module
The bumper module raised a flag, when the obstacle is
close to the robot. As to avoid collision, this information is
sent to the movement control to block the forward
movement.
J. Hardware Abstract Layer (HAL)
The robot hardware abstract layer provides a single
control system for all robots. The main function is to
sendthe movement commands to the robot and to collect
the sensor data back. During the navigation, the sensor
data are saved in the log file, are used for other modules on
RECoM internally, and are sent in parallel to the GUI via
the PeLoTe server. Furthermore, HAL also provides
possibilities to initialize and calibrate sensors, whenever
the operator wants.
Even the above modules are defined for all entities, some
are used by an entity, might not be used for another
entities. Most of the described modules are used for the
mapping robot. For the human following robot, some
modules are not fully used and in extra, a module
responsible for the human following is added. This module
checks the position of the human, the robot position, and
the obstacle positions. Then commands are generated for
the movement module on the robot, wrapped by the HAL,
in order to keep certain distance from the human and also
to avoid collision to obstacles.
In parallel, the PeLoTe server dispatches all received
data, mainly position of all entities, to the connected
teleoperator GUI stations, including the GUI used by the
man in action, giving good mission overview to all. On

214
 Fig.5. Robot founds a victim

Fig. 4. The PeLoTe experiment in the firefighter training house

of Wuerzburg, Germany

PeLoTe server, there are also some other modules running

internally such as the CoLo, the global map builder, and
the planning module.
IV. EXPERIMENTS
The PeLoTe experiments were performed in the
firefighter training house of Wuerzburg, and in the Juliux
Maxmilian University of Wuerzburg. The experiments are
done under different scenario. As shown in Fig. 4, the
search and rescue team members are in the living room of Fig. 6. Dangerouse zone (left) and dangerous exit (right)
the firefighter training house. The PeLoTe rescue team
consists of a fireman with the personal assistance and
navigation systems (PeNa) [3-5], a mapping robot, a
human following robot. In addition, a victim represented
by a doll is put on a chair in front of firing sofa. For the
experiment in the university, the simulated firing scenario
are designed and constructed.
A. Description of the PeLoTe system operation
Initially, the map of the house is obtained and created as
a PeLoTe global map. All entities are set up at a starting
position on the map and wait for commands from the
operator. At the beginning, the operator starts voice
communication with human entity and makes confirmation
for prompting. Then, the operator starts planning for the
Fig. 7. Robots and beacons
mission for each entity and sent the planned paths to each
entity. The human entity and mapping robot start
that the robot stops and waits for the next command from
following the individually obtained path, which could be
operator. The example of simulated dangerous area and
different from each other. The human entity and the
dangerous exit is shown in Fig. 6. The mapping robot was
mapping robot can also update the map, when they found
commanded to investigate in these area, which is harmful
victims or dangerous area. Meanwhile, the human
for human. During the mission, the sensor data and the
following robot receives no plan, instead, follows the
entity positions are displayed on the operator GUI whereas
human entities during the whole mission. The mission is
the voice communication is continuously hold between
ended when the time limitation is reached or when the area
human entity and teleoperator throughout the mission.
is completely investigated.
Furthermore, the robot localization is further improved
B. The robot operations by the additional ultrasonic beacon system described in [6,
7]. The beacon system corrects the entity positions and
As shown in Fig. 5, the doll represents the victim and the
headings in areas covered by beacons. The 4 beacon
wall is built using carpet for convenience in construction.
sensors are installed in the scenario area shown in Fig. 7
During the operation, when the robot found a victim, the
and a beacon sensor is mounted on each entity. This
positions of victims are updated on the global map. After
system provides measurement of distances between the

215
fixed beacons and the moving beacons that are mounted on
entities. The position is corrected using the dynamic
multilateration algorithm.
C. The PeLoTe GUI
Fig. 8 shows the PeLoTe GUI described in [8, 9]. When
the operator sends new path to the robot, the generated
path is shown up as concatenated straight lines on the
global map. The small scale map with a zoom bar is
available at the bottom right of the panel. The entities
position and heading are represented by triangles. Each
entity is recognized by colors on the same global
coordinate. Their positions are always updated during the
mission. On the left hand side of the panel, there are
symbols of victim, gas, fire, and dangerous area symbols,
which could be added later on the map for map updating.
The message dialog box is also available at the bottom of
the monitor. This shows message from entities e.g. robot
founds victim, low battery.
D. Experimental results and discussion
1) The experiment in the firefighter training house: the
firemen observed the PeLoTe system during the operation
and they were interviewed after the demonstration. They
agreed that the PeLoTe system is useful in the search and
rescue mission. The robots have advantages in harmful
environment such as toxic gas, explosion, nuclear area,
collapse. The human following robot could also carry the
equipment, taking over the work from human in the
destructive area, and doing measurement. The most
important information for search and rescue are, where I
am, where the exit is, and where the way back is. In some
situation, someone would loose his way out from the
building. In this case, the localization is necessary.
Furthermore, the robots are expected to close the valve and
check the chemical substances in the future. However, the
firemen believe that they would rely on themselves more
than robot decisions in the non harmful area.
2) The final experiment at the university: The map of the
experimental area is presented in the PeLoTe session,
“Human-Computer Interaction in the PeLoTe rescue
system.” The map represents the firing scenario and shows
the location of the dangerous area, the firing area, the gas
area, the activated and not activated fire alarm, the victims,
and the exits. The simulated firing scenario in the building
of the university represents the gas, fire, dangerous zone
and dangerous exit by the symbols printed on a white
paper that are placed on the ground. The experiment area
was closed and all lights are turned off during the
experiment to lower the visibility of human.
Before the experiments started, the firemen were trained
for understanding the mission and knowing how to equip
the PeLoTe system. The mission has 25 minutes time
limitation. Before the time is over, the firemen should
search and rescue all victims and also come out from the
firing scenario. The scenario was setup as the complicated
and low visibility large area. During the mission, the
victim volunteers were crying for requesting help, at the
position where the doll is placed, until they are found and
rescued. The building collapse was also simulated using
216
Fig. 8. PeLoTe GUI with generated path and entities position
walls and collapsed sound. The path is closed behind the
firemen after he has passed through the destructive point.
They would hear the noise but they couldn’t see what was
happening. Finally, some firemen loosed the way they
have passed and loosed their orientations. Most of the
firemen thought that the scenario was complicated and was
hard for them to find the way out.
In a team, one fireman is an operator and another goes
into the firing scenario. After each experiment, the firemen
must fill the evaluation form about the experiment.
Without the PeLoTe system, some of them failed to find
the way out before the time is over because they didn’t see
the scenario and they didn’t know where they were. In the
opposite, the team with PeLoTe system could know their
position during the mission using PeLoTe system and
finally could come back to the exit.
The experimental results related to questionnaire are
presented in the PeLoTe session, “Human-Computer
Interaction in the PeLoTe rescue system.” There, the
comparisons between the experimental results with and
without the PeLoTo system are also provided. The
operating time of each experiment, the coverage of area in
percentage, the number for fire area found, the number of
dangerous area found, and the number of victim found are
compared. For the final experiment with PeLoTe system,
from six experiments, the average time of all team is 25.2
minutes and the rescue team covered 98.3 % of the overall
area. All victims are rescue where as the average of fire
area found is 3-4 from the total of 4 and dangerous area
found is 3-5 from the total of 5.
V. CONCLUSIONS
This paper presents the mobile robots used in search and
rescue operations to support the hybrid telematic teams in
PeLoTe project. As a member of the team, the robots have
functionalities for searching victims, investigating
dangerous area or low visibility area, providing sensor data
for mapping and following human. The experiment were
performed in the firefighter training house in Wuerzburg
and in the Juliux Maxmilian University of Wuerzburg. The
firemen performed the test using the PeLoTe equipment. It
was demonstrated, that semi-autonomous robots may
improve quality of whole missions, mainly in the terms of
 speed, coverage area exploration and lower danger to the
firefighters. The whole PeLoTe system showed to be
effective for the large-scale complicated search and rescue
missions.
ACKNOWLEDGMENT
The work has been supported under the “PeLoTe-Building
Present through Localization for Hybrid Telematic
Systems” project within the IST-2001-FET framework.
The authors would like to thank the contributions from our
consortium partners at the Julius-Maximilians University
Würzburg, the Czech Technical University in Prague,
Helsinki University of Technology, and Certicon a.s.
REFERENCES
[1] F. Driewer, H. Baier, K. Schilling, J. Pavlicek, L. Preucil, M. Kulich,
N. Ruangpayoongsak, H. Roth, J. Saarinen, J. Suomela, A. Halme,
“Hybrid Telematic Teams for Search and Rescue Operations,”
Proceedings of the SSRR'04, IEEE International Workshop on Safety,
Security, and Rescue Robotics, Bonn, Germany, ISBN: 3-8167-6556-
4, May 2004.
[2] J. Kuhle, H. Roth, and N. Ruangpayoongsak, “MOBILE ROBOTS
and airships in a multi-robot team,” The 1st IFAC Symposium on
Telematics Applications in Automation and Robotics, Helsinki
University of Technology, Finland, pp. 67-72, June 2004.
[3] J. Saarinen, R. Mazl, P. Ernest, J. Suomela, and L. Preucil, “Sensors
And Methods For Human Dead Reckoning,” Proceedings of the 8th
Conference on Intelligent Autonomous Systems, IAS-8, Netherlands,
Amsterdam March 10-13 2004.
[4] J. Saarinen, J. Suomela, A. Halme and J. Pavlícek, “Multientity
Rescue System,” Proceedings of the 1st IFAC Symposium on
Telematics Applications in Automation and Robotics, Helsinki, June
2004
[5] J. Saarinen, R. Mazl, M. Kulich, J. Suomela, L. Preucil and A.
Halme, “Methods For Personal Localisation And Mapping,”
Proceedings of the 5th IFAC symposium on Intelligent Autonomous
Vehicles, IAV2004. Portugal, Lisbon, July 5 – 7, 2004.
[6] M. Kulich, J. Pavlíþek, J. Chudoba, R. Mázl, L. PĜeuþil, “Hybrid
Telematic Systems for Rescue Missions,” Cybernetics and Systems
2004, Vienna: Austrian Society for Cybernetics Studies, 2004, vol.
1,2, p. 731-736. ISBN 3-85206-169-5.
[7] J. Chudoba L. Preucil, “Localization using ultrasonic beacons,” the
3rd International Congress on Mechatronics 2004, Prague, 2004.
[8] F. Driewer, H. Baier, K. Schilling, “Robot / Human Interfaces For
Rescue Teams,” Preprints IFAC Symposium on Telematics
Applications in Automation and Robotics, Helsinki 2004, p. 79-84.
[9] K. Schilling, F. Driewer, H. Baier, “User Interfaces for Robots in
Rescue Operations,” Proceedings IFAC/IFIP/IFORS/IEA Symposium
Analysis, Design and Evaluation of Human-Machine Systems,
Atlanta, USA, 2004.

217

View publication stats